Date:
14/2-2014 - 18/2-2014
14/2-2014 - 18/2-2014
Duration of activity:
9.30 - 13, 10-12, 10-13.30
Group members participating:
Benjamin, Christina, Levi
Benjamin, Christina, Levi
Goal for the lab session:
Complete exercise 1 through 6.
Complete exercise 1 through 6.
Plan for the activities:
Go through the exercises one by one, completing them to the extent possible.
Go through the exercises one by one, completing them to the extent possible.
Results obtained during lab session:
Exercise 1: measuring distance to objects
Object: Coffee cup
Exercise 1: measuring distance to objects
Object: Coffee cup
 |
| The coffee cup was placed at different lengths from the NXT. |
Distance
|
Sensor reading
|
25 cm
|
35
|
40 cm
|
48
|
50 cm
|
56
|
The readings are shown to be higher than the actual distance.
Object: Lego box
 | |
|
Distance
|
Sensor reading
|
25 cm
|
35
|
40 cm
|
48
|
50 cm
|
56
|
The readings are shown to be higher than the actual distance, as the case was with the coffee cup.
Object: Trash can
 | |
|
Distance
|
Sensor reading
|
15 cm
|
16
|
40 cm
|
40
|
90 cm
|
90
|
135 cm
|
137
|
The readings were very accurate, so a fourth test was done, where the reading differed again by being larger than the actual distance.
To sum up:
The readings are higher than the actual distance when using the cup and box.
The reason why the readings are so much higher than the actual distance when using the coffee cup, can be because the coffee cup is shorter and the echo therefore has a more tilted angle (and therefore a longer distance to travel back to the sensor).
When using the trash can (that has an almost straight vertical surface), the readings are close to the actual distance. This can be because the echo’s traveled distance is less tilted and comes back horizontally.Exercise 2:
We tried to reduce the sleep timer to 30ms. This seemed to make a minor increase in the speed of updating the value on the lcd, but not very much.
We suspect that there is a lower bound on about 200-300 msec.
We also tried with 3000ms (3 seconds), which of course made the number update only every 3rd second.
Exercise 3:
We tried putting the car on a table with the sensor facing a vertical board, but after getting the reading to output 180 on the lcd and moving it further away on the flat table, the reading shifted to 255 immediately, and it was not possible to get a reading between 180 and 255.
We tried placing the car on the floor facing a vertical board with a height of about 1.5 m and got up to the reading of 230 before is shifted to 255, and it was not possible to get a reading between 230 and 255.
When using the same vertical board and lifting the car from the floor, the reading got up to 245 before shifting to 255.
It is possible to make the sensor reading output 254 on the lcd. This was done by holding the car in the hand and backing away with the car’s sensor facing a wall, further and further away from the wall, until it was at a reading of 254. It was not easy placing the car to read this value, because it very often, with just a minor tilt of the car, read 255.
To sum up:
We suspect that this difficulty getting a steady reading when placing the car on a surface is that the surface’s reflections disturb the measurements. It also have something to do with the surface the echo is reflecting on. From these experiments we suspect that to obtain the most accurate results, the car should face a vertical surface that is large enough for the echo to only reflect on the surface even when the car is far from the surface, and that the car should be in the vertical center of the board, and not on the floor. This placement of the car in the air is of course not possible, but thinking about the consequences of measuring distance when placing the car on the floor is important.Time limit for measurement:
We take the distance and divide it with the speed, which will give us the time of flight:254cm / 340290cm/sec = 0.0007464sec = 0.7464msSince is has to travel both forth and back again, the value has to be doubled: 2*0.7464ms = 1.4928msThis gives us an upper bound for sample rate at 1.4928ms. We have tried to come up with a scenario which would interfere with this bound, but we could not come up with anything where a such small number would matter enough to be an actual limit.
Tracker beam:
The car tried to stay at distance 35, by reversing if the distance was less than 35. When there was no object in front of it, as in distance = 255, it set both engines to 100 and did not update the LCD.
Exercise 4:
The program uses proportional control. It can be deducted from the code, as time is not an element in the calculations. While an integral control uses instantaneous error over time in its calculations and a derivative control uses the slope of error over time, the tracker code does neither of these. The tracker uses proportional control. This can be seen in two places: 1. Exercise 5 states clearly that tracker.java uses proportional control. 2. In tracker.java we see these lines:
error = distance - desiredDistance;
power = (int)(gain * error);
They match the formula for proportional control, as seen on the Wikipedia page on PID:
Exercise 5:
Using the given pseudocode as inspiration, we implemented a derivative controller to the tracker code. The PD controller code looks like this:
oldError = error;
error = distance - desiredDistance;
derivative = (error - oldError)/dt;
power = (int)(pGain * error)+(int)(dGain * derivative);
We experimented with different values for the constants but it always resulted in overshooting the desired distance. We then experimented with different values for minPower, to get the car to stop. We found the sweet-spot at minPower = 30, pGain = 5, dGain = 60. The real breakthrough came when we lowered our sleeptime(dt) from 300 to 30. This allowed the calculations to be performed a lot quicker, and resulted in the results which can be seen in the video and graphs below.
The graph shows how the motor is powered (the blue circle points) to make the car get closer to the desired distance, and then oscillates between less and more power to control the cars movement, until it finally stops at a distance of 35 cm.
Exercise 6:
Mounting:
Our take on a wall follower algorithm is a bit different from Hurbain’s, since it is inspired from Tracker.java. We take the error distance into consideration when deciding the movement speed of the car, and thus create a proportional factor. If the car is too close to the wall, the right wheel will be set to a pre-defined minimum power, and the left wheel will be set to a power depending on how close to the wall the car is. This is of course the opposite when the car is too far away from the wall. Hurbain is using predefined speeds including reverse speeds, and thus also made it possible for the car to turn in place.
The graph above shows our logged data from running the program along a straight wall. Despite the large amount of values above 35, which was our preferred distance, the car drove arguably straight as shown in the video. We could not find out why there were so many misfitting values in the log, since the car as mentioned drove arguably well. However if we should make the car drive more straight, we could make the minimum power depend on the error distance as well, or we could check on for how long it has been too close to or too far from the wall, and then de- or increase the power.
Because of the large amount of high/incorrect values it would not make sense to calculate the average and standard deviation.
The car in action can be seen here:
Conclusion:
We have completed the exercises for the lab session and experimented with the ultrasonic sensor, and thus completed the goal.
Ingen kommentarer:
Send en kommentar