Lab session 7

Attendees: Jesper Jakobsen and Michael Nygaard Pedersen

Work time: 9.0o - 13.00

Goal

The goal is to create and investigate simple Braitenberg creatures.

Sub goals

To program three different types of Braitenberg creatures and investigates the behavior of its own and among other Braitenberg creatures.

Plan

· Build a basic robot with the properties of the Braitenberg creature (2a and 2b from Ref1)

· Program and test a light following Braitenberg creature

· Evaluate a light avoiding Braitenberg creature

· Compare direct control form and comparator control form.

· Evaluate and implement light measurement filter.

Results

Description of experiment

Ref2

Programming attempts

Four different approaches where either fully implemented or investigated during this lab session.

Direct control

The direct control works in almost the same way as the filtered implementation, which is presented in the next subparagraph and dealt with in detail.

Filtered direct control

The Braitenberg vehicles are constructed as shown in Ref1. It basically consists of two light sensors and two motors.

The values read by the light sensors are fed directly to two motors, respectively, as shown in Ref1. Vehicle 2a avoids the light while Vehicle 2b searches the light. To change the functionality of one vehicle to the other, the light sensor/motor connections are simply swapped.

The “estimate” value is set to 50 as default and offset is 250 - Both values are based on experiments. The “light searcher” essentially works as follows:

public void searchLight() {

while (!Button.ENTER.isPressed()) {

normVal1 = ls1.getNormalizedLightValue();

normVal2 = ls2.getNormalizedLightValue();

// Filter algorithm

estimate1 = estimate1 + (filterKoef*(normVal1 - estimate1));

estimate2 = estimate2 + (filterKoef*(normVal2 - estimate2));

normVal1 = (int)estimate1;

normVal2 = (int)estimate2;

// Range algorithm - Not used in this implementation

calibrateSensor(normVal1); calibrateSensor(normVal2);

// Search algorithm.

leftMotor.controlMotor(normVal1-offset,forward);

rightMotor.controlMotor(normVal2-offset,forward);

}

}

The light sensor values are read, filtered and normalized to comply with the .controlMotor method. The filter “smoothes” the operation of the vehicle by slowly integrating weighed changes in light intensity.

Differential control

Another way of optimizing the behavior is to make the light measurement depended of one another. By subtracting the two measured values, the ambient light level is less important, when the speed is determined. The direction is determined by the polarization of the subtraction and the turning and drive speed can be calculated based on the difference.

Filtered direct control in two threads

To make the Braitenburg creature even more real, the two inputs with the belonging output was tried implemented in two different threads (two brain halves controlling each side). The idea was to take implemented filter control and put half of the functionality into one class and the other half into another. The main class should then extend threads and each class should then run independently in two threads. The final implementation was not made, because of the used time.

Problems encountered

When the Braitenberg creature was tried implemented in threads there was several compiler errors and they were not resolved within the lab session.

Conclusion

The NXT behavior was never tested among other NXTs, because only few NXTs where actual working. The designed robot was borrowed from another group because LegeCarstens’ group member with access to the robot never showed up. The written software worked perfectly on the other robot.

References

Ref 1: Notes on construction of Braitenberg's Vehicles, Chapter 1-5 of Braitenbergs book

Ref2: Introduction to Machina Speculatrix and Braitenberg Vehicles

Lab session 6

08102009

Attendees: Jesper Jakobsen, Mads Hansen Lund and Michael Nygaard Pedersen

Goal

In this lab session we will try to make a car that drive as fast as possible following the Alishan train track. The Alishan train track has been used at a robot competition called World Robot Olympiad in 2007 (Ref 1).

Sub goals

To evaluate the sub goals a detailed analysis of the track is made.

Track analysis

Figure 1 shows the track with all the issues needed to be resolved. All the state identifiers are unique for this lab session and might be used more than once, but will always refer to the same state.

Figure 1 - Alishan train track top view

1: The robot should drive forward in the beginning and activate line following sequence, when at least two sensors detect a white surface.

2: The robot should be orientated on the right side of the line in the first straight line.

Figure 2 - Follow simple line

3: When the center sensor and sensor on the inside of the corner reads a black value the robot is set in reverse and will now detect and drive more careful.

Figure 3 - Detect sharp corner

4: When the sharp corner functionality has been executed the standard line following code is activated again. But the line orientation should be shifted after X seconds and the sharp corner functionality is also inverted.

Figure 4 - Change side to keep orientation on the left side for the next corner

5: If all sensors detect black a 180 degree turn should be performed after X seconds and both the line orientation and sharp corner functionality must be reversed yet again after X seconds of blind mode to ignore the big black line across the track. Then the program is just executed like from the bottom and up.

Figure 5 - Wait and turn 180 and evaluate that track is half finished

When all three sensors detect green for the second time the program is stopped and total time is logged.

Plan

To sum up a self explaining pseudo flowchart for the main algorithm is presented in Figure 6.

Figure 6 - Pseudo flowchart

The plan is to implement this general Alishan train track algorithm and apply some or all the necessary exception states to complete at least one half of the track.

Results

Description of robot

The racing vehicle utilizes three RCX light sensors located in front of the steering wheels to gather information about the racing track in advance. The three light sensors are fixed in position with respect to each other but can move up and down in order to keep the same distance to the surface. This done with an assistant ''distance wheel'' which insures that the light sensors always are kept in a constant distance from the track (see Figure 7).

Figure 7 - Picture of robot

The picture to the right in figure 7 shows a logged time for a run on the track in milliseconds.

Software description

Folowing flow chart diagrams and related text should be read together with the uploaded code (REF3).

The concept for the software is based on the linefollower from Lab Sesion 1 (REF2). The linefolower has been modified for the Alishan train track. The main differences are illustrated in Figure 8 where the program has a optional line side orientation.

Figure 8: Flow chart for the main concept.

The 90 degrees corners requiere an more aggresive turn, which is peformed with a reverse motor drives and slower speed illustrated in Figure 9.

Figure 9: Flow chart of the two turning modes (the hard turn is activated by a 90 degrees corner).

When the robot encounters a 90 degrees corner it passes the corner by failure, but registers that an error has been made. To get back on track the robot move slightly backwards and proceed with a more gentle tracking method and more aggressive handling.

Figure 10: Flowchart illustrates that the robot reverse back to find the line again when it arrives at a 90 degrees corner.

Problems encountered

At first the light sensors were located too close to the steering wheels which made the vehicle unable to react to changes in the racing track.

The line follower uses a bang-bang control algorithm, which at first made the vehicle sway relative violently from side to side.

The biggest problem was to make it through the 90° corners. When encountering a corner the line follower algorithm would cause the vehicle to race off track.

The final algorithm used causes the vehicle to be relatively slow since it needs to slow down to manage the 90° corners.

When encountering the black line separating the last slope and the highest plateau, the vehicle sometimes think it has encountered a corner and starts moving backwards.

The battery needs a fair amount of charge to be to drive uphill.

Conclusion

The robot did not reach the final destination, but all the principles from the track analysis has been investigated and proven to work. The robot is very slow but works very well uphill, which is the only functionality fully implemented. This video shows the robot in action:

References

Ref 1 http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson6.dir/Lesson.html

REF2 http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson1.dir/Lesson.html

REF3 http://legocarsten.blogspot.com/2009/10/code-from-lab-session-6.html

Lab session 5

02102009

Attendees: Jesper Jakobsen, Mads Hansen Lund og Michael Nygaard Pedersen

Goal

In this lesson we will modify the LEGO 9797 car and make it follow a black line and stop at the end of the line when the car drives into a goal zone - a green rectangular piece of paper at the end of the black line. The idea is that we will try to use the light sensor to detect three different colors.

Sub goals

To build a simple robot inspired by the LEGO 9797 building instructions.

To evaluate a black and white distinguisher java class and expand the functionality to also detect the color green.

Plan

· Build a robot with a light sensor

· Code the robot and evaluate the result based on default code

· Experiments involving different environments to evaluate color distinguishing performance

· Test the expanded class and implement line follower functionality

Results

Description of experiment

Beneath the main sequence of the line follower combined with a stop sequence is presented. A “time1” variable is declared once with starts. The total operation time (totalTime) is calculated in the stop sequence.

// Line follower

if (sensor1.light() <>

// On white, turn right

Car.forward(0, power);

}

else{

Car.forward(power, 0);

}

// Stop at green

if( sensor1.light() <> sensor1.getGreenValue()-Hysteresis){

time2 = System.currentTimeMillis();

totalTime = time2 – time1;

Car.forward(0, 0);

}

Programming attempts

The original code was expanded and will now calibrate for three different colors. The main functionality is shown beneath.

public boolean black() {

return (ls.readValue()< blackWhiteThreshold && ls.readValue()< blackGreenThreshold);

}

public boolean white() {

return (ls.readValue()> blackWhiteThreshold && ls.readValue()> greenWhiteThreshold);

}

public boolean green() {

return (ls.readValue()< greenWhiteThreshold && ls.readValue()> blackWhiteThreshold);

}

Measurements

The light sensors have been evaluated in Lab session 1 . The experiment in this Lab session has been done in the same way as Lab session 1.

Light reflection measurements

	Sensor 1	Sensor 2	Sensor 3
Lightgreen	29	25	30
Green	23	16	23
White	33	28	33
Black	22	15	22

Table 1 – Measurement made to distinguish between white, green and black

Pictures of Lego model

Figure 1 - Picture of robot

Problems encountered

The battery is a common issue when building a NXT robot. The robot performs very bad, if the battery is not fully charged.

Conclusion

The color disguising class can easily be expanded and a stop sequence has been added to the line follower code with success.

References

Ref 1 http://legocarsten.blogspot.com/2009/09/lab-session-1.html