Lab session 7 : Braitenberg vehicles

Date: 28. October 2010

Duration of activity: 5 hours
Group members participating : Michal Owsinski, Michaël Ludmann and Guillaume Depoyant.

I. Objectives and summary

I.1 Objective

To build and program Braitenberg vehicles

Figure 1 Braitenberg vehicles 1, 2a and 2b

II. Summary


During this lab session, we managed to :

• Build and program the three Braitenberg vehicles
• Experiment with them and find the relevance of each of them
• Improve their design in order to get better responses
• Find new tasks for the robot with two light sensors thanks to this improvement

II. Understanding Braitenberg vehicles


I. Vehicle 1 with a sound sensor

In vehicle 1 we used our old LEGO 9797 construction, 1 sound sensor and 2 motors (working as one actuator). We programmed the robot as shown in Figure 1, vehicle 1 - sending the normalized value from the sound sensor to the motors. Effect was as expected,The vehicle was driving forward when a noise was made near the sound sensor. It was driving faster when louder the sound was. Next video shows the results.

II. Vehicle 2 with two light sensors

We rebuilt our LEGO 9797 and fit it with 2 light sensors placed 2 cm above the surface pointed in the forward direction. Then we programmed our robot as shown on Figure 1 Vehicle 2b (left sensor normalized values were sent to right motor and right sensor normalized values were sent to left motor). The vehicle followed focused light (a flashlight) and with its behavior begun to remind a moth (driving moth :) ). The speed of vehicle was related to the amount of light detected by the light sensors.

The difference between vehicle 2a and 2b is that vehicle 2a will drive away from the light source (behavior of a bat).

If we modify our vehicles (2a and 2b) to an inhibition connection (the more the less) we will get a vehicle driving constantly until finding the light source (look at the last video).

III. Improvements


I. Updating MIN/MAX light values

We followed the main idea of Tom Deans with the constants MAX_LIGHT and MIN_LIGHT, that is to say that we allowed the robot to set his own values, updating them over all the sample values obtained during the lifetime of the vehicle. (cf video)

This way the vehicle was able to be tested in different environnements.Instead of changing the constants depending on the place we tested the robot, we could have reliable results in dark or bright places.

The next step was to take the highest/lowest value for the Max/Min among the last N values sampled instead of taking all the values sampled in the lifetime of the robot. We simply used a queue in order to implement it and it worked better than expected like you'll see in the next part.

II. Results and new possibility / functionality

The next two videos show the implementation of self updating of the min/max values.

The first one is with the update during all the lifetime. As the video will show you, the results are efficient enough and this for all type of places (dark/bright) but we couldn't change the robot from one environnement to another because the min/max was causing some unpredictable behaviours. Indeed, the robot was evolving in a dark room with a constant MAX_LIGHT meant to be used in a bright room.

This way, the second video shows us how the problem can be solved by implementing the queue of the last N values sampled. We took N = 1000, this means that the robot only took the values from the last 10 seconds. The brightness could be changed in any way, the robot needed at most 10 seconds adapt himself and try to follow the light (this explains why the robot has to stop sometimes).

III. Using different threads of control

In our previous algorithm, both motors are always getting their commands at the same time, since we use only one thread : there is a single thread of control where the two light sensors are sampled and the two power values are put out to the motors.

We tried to implement the same task by using one thread for each couple of sensor and motor (i.e. each connection). In this case, it is the thread managers (scheduler) responsibility to make sure that every module of the robot gets the required CPU time to compute its reactions to the environment. Hence the modules work without being directly linked to each other.

This is quite useful while dealing with more complex systems where we need independent modules that do not influence each other (see next lab session for more implementation of this idea).

IV. References

• [1], Tom Dean, Introduction to Machina Speculatrix and Braitenberg Vehicles
• [2], Tom Dean, Notes on construction of Braitenberg's Vehicles, Chapter 1-5 of Braitenbergs book