Lab session 2:

After mounting the robot with the ultrasonic sensor on top we compiled and upload the SonicSensorTest.java test program. The purposed of this application was to analyze the response of the ultrasonic sensor provided with the lego box.

The first experiment consisted on checking the values read by the sensor while an object was located close to 254 cm. In this case the original SonicSensorTest application was used with no modifications. The sensor was able to detect an object at that distance if it was a solid surface. In that case we used the cover of the lego box. The sensor was retrieving the proper measurements.

If instead of using a solid surface we were using a jacket, the cloth was absorbing the ultrasonic waves without reflective them, breaking the working principle of the sensor (which was unable to detect the eco of the ultrasonic burst).

What is the time limit for the measurement?

The ultrasonic burst has to travel 2,5 meters until it reaches the object and goes back, covering a total distance of 5 meters. This implies that it will take a minimum time of 14,6 milliseconds (5m / 340.29 m/s = 0.0146 sec). This time is defining the theoretical limit.

In the original SonicSensorTest, the getDistance method is executed every 300 milliseconds, since the thread is executing the method Thread.sleep(300); inside the while loop. If we modify this figure to values closer to the theoretical limit we can analyse the response of the sensor. We found out that if this sleeping period is decreased to 30 ms, which is close to twice the time it takes the ultrasonic burst to reach the object and go back, the maximum reliable distance is decreased to 1 meter. Some additional results can be found in the following table.

Sleeping period [ms]	Maximum reliable distance [ms]
50	1,5
30	1
10	0,5

It can be concluded that

• The lower the sleeping time the faster the measurements turn out to be unreliable.
• There are additional factors that limit the usage of the ultrasonic sensor besides the sound propagation, like the signal adquisition, signal conversion, communication through the I2C bus between the sensor and the processor, etc…

Tracker Beam

The purpose of the tracker beam is to advance until it reaches a distance of 35 cm with an object, which will be kept during program execution.

At the beginning, as explained in the problem statement, the power to the car motors was the controlled variable and the distance was the measured variable. This kind of control is known as proportional control. In the initial application the Minimum power was set to 60 with a gain of 0,5 resulting on 3 to 4 cm oscillations when the robot was around the 35 cm distance.

The behaviour of the car can be modified if different values for the gain and minimum power are set. Some of the tests we run are the following ones:

Minimum power	Gain	Maintained distance [cm]
50	0,5	44
50	1	37

Additional integral control can be added to reduce the error between the maintained distance and the desired one. A third element, the differential term, can be added to control the overshooting, so oscillations would be reduced. If these three elements are combined, the controller is called PID controller (Proportional Integral Differential controller).
Wall Follower

We have implemented the a modified three-state wall follower algorithm. We have defined 4 different distance areas in where we change the behaviour of the car. The precondition for the algorithm is that the car is moving seing the wall at its right side.

Dist Area 4: (2 cm from wall) Car moves backward
Dist Area 3: (6 cm from wal) Car turns left
Dist Area 2: (12 cm from wall) Car moves forward
Dist Area 1: (40 cm from wall) Car turns rigth

In all the above distance areas the car motor is powered with at fixed value that ensures a steady slow speed.
When the distance is greater than area 4 it is using a proportional gain based on the distance it measures to the wall. The algorithm has not yet been tested since we ran out of battery and could not get the NXT working again. We will test it first time in the next lab exercise.

Update on Lab session 2 - 16th September

The NXT problem was solved by uploading the lejOS firmware again. Once the brick was reflashed, we continue working with the wall follower problem. We add some modifications to the source code, incorporating the suggestions from the exercises on page 179 [1].

The NQC program is first of all setting the sensors that the robot is going to use. Some small time delays are added so the different peripherals can be initialized. This can be seen in the following lines:

SetSensor(SENSOR_1,SENSOR_LIGHT);
Wait(100); // Charge GP2D12 sensor
SetUserDisplay(value,0); // Display distance (remove for RCX firmware 1.5)

SetSensor(SENSOR_1,SENSOR_TOUCH); // Activate sensor
Wait(5);
SetSensorMode(SENSOR_1,SENSOR_MODE_RAW);
value=SENSOR_1; // Get distance
SetSensor(SENSOR_1,SENSOR_LIGHT); // Re-cahrge sensor for next time
Wait(25);

The default action is to move forward left and right motors, so associated values to the defines MFW are assigned to motl and motor. Next step is to check if the robot is close or far away from the wall, and perform different corrections depending on how close or far it is. In the following code snippet it can be seen the actions corresponding to the "close to the wall case".

if (x>=XL1) // Close to the wall
{
if (x>=XL3)
{
motr=MREV; // Very close, turn in place
}
else if (x>=XL2)
{
motr=MOFF; // close enough, turn
}
else if (x>=XL1)
{
motr=MFLT; // a bit too close, shallow turn
}

}

The determined action in the previous conditional blocks is executed for each motor by using two switch statements (one per motor). As an example, it can be seen the first switch statement, that corresponds to the right motor:

switch(motr)
{
case MFWD:
OnFwd(OUT_C);
break;
case MFLT:
Float(OUT_C);
break;
case MOFF:
Off(OUT_C);
break;
case MREV:
OnRev(OUT_C);
break;
}

Implementation and partial modification in java.

In our java application we have defined different parameters that can be adjusted in order to implement different control strategies. These parameters are defining distance, power and sampling time.

int desiredDistance = 0, // cm to wall
minPower = 60,
slowPower = 20, // + minPower
maxPower = 90,
rightPower = 6, // Power difference to turn
leftPower = 3,
sampleTime = 50; // Time between reading sensor

Different thresholds for determining how close the robot is to the wall are defined. Depending on the comparison result between the error value and those thresholds, different actions will be performed.

int CloseWall1 = 30, // Turn Left
CloseWall2 = 20, // Forward
CloseWall3 = 15; // Turn Right

The main control loop is performing a moving average filtering, so it can compensate possible errors in the readings. This is done as follows:

distance = us.getDistance();
distance = distance/2 + last_distance/2;

In the case wall is detected the control strategy will evaluate three different cases, comparing the error figure with the distance to the wall. Depending on the comparison results, different actions will be performed, which could be turn right, move forward or turn let. In the case the error is greater than the expected, the motors will be controlled with the previously defined proportional gain and drive forward.
Finally this routing will be repeated with a period defined by the sampling time.

Final video of wall follower:
http://www.youtube.com/watch?v=TKmqrkfouvI