Skip to content
GitLab

Lesson2 · Changes

Page history
cvf06035 created page: Lesson2 authored by Camilla Marie Vinther Frederiksen's avatar Camilla Marie Vinther Frederiksen
Hide whitespace changes
Inline Side-by-side
Lesson2.md 0 → 100644
View page @ b450eed6
## Lab Notebook 2
**Date:** 18th of February 2016
**Group number:** Group 14
**Group members participating:** Camilla Vinther Frederiksen, Ida Larsen-Ledet, Nicolai Nibe and Emil Platz
**Activity duration:** 5 hours
## Goal
Do not kill Frej (the robot).
To understand and implement the use of ultrasound sensors with the NXT robot through the completion of the exercises as
described in [lesson plan 2](http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson2.dir/Lesson.html)
## Plan
Our plan is to follow the instructions and complete the task of the lesson plan, while each group member has a primary job. Ida and Nicolai will perform the
measurements with the NXT, Camilla will take notes for our report, and Emil will control all compiling and running of code.
We also intend to take some pictures and videos of the exercises that could be useful in explaining our 'scientific' approach.
## Results
### Exercise 1: Testing ultrasound sensor
We ran the program **sonicSensorTest.java** as an NXT program on the robot. This made the robot display a number on the LCD,
indicating that the sensors sensed distance to the nearest object in front of the ultrasound sensor.
The robot was placed facing various objects at various distances, where we ourselves measured and noted the distance from the sensor
to the object with a ruler, and then noted the distance measured by the ultrasound sensor, that was displayed on the LCD, as well.
The data is shown in table 1.
| Actual distance | Sensed distance | Object |
| --- | --- | --- |
| 18 cm | 21 cm | Back of computer |
| 41 cm | 42 cm | Back of computer |
| 12 cm | 16 cm | Back of computer |
| 34 cm | 35 cm | Nicolai's leg |
| 20 cm | 23 cm | Nicolai's leg |
| 47 cm | 40 cm | Nicolai's leg |
| 58 cm | 60 cm | Wall |
| 80 cm | 82-94 cm | Wall |
| 120 cm | 121-123 cm | Wall |
| 181 cm | 255 'cm' | Wall |
Table 1: Measured distance and the ultrasound sensed distance. The ranges indicate that the sensor fluctuated between these
sensed distances.
We noted and observed several things during the experiment. First of all, it is worth noting that the wall had a 'rough'-textured soft
wallpaper, which might influence the reflection of sound from our sensor. Secondly, the sensor occationally displayed a distance
of 255, even if the actual distance was much shorter. This is not an actual measured distance, but rather the result of the sensor not
receiving any sound wave back. This is the equivelant of a missed 'ping', which causes the sensor to assume that the distance
to the nearest object is greater than 254, as this is the longest distance the sensor can measure.
In addition to testing the sensor with various surfaces and distances, we experimented with different angles with the same distance
and surface, in this case a door, with a (roughly) perpendicular distance of 31 cm. The purpose of these measurements was to figure out at what
threshold the angle to the wall became too high/low for the sensor to accurately sense a distance to the wall.
The collected data is shown in table 2.
| ~ Angle | Actual distance | Sensed distance |
| ----- | ----- | ----- |
| 45 | 31 cm | 255 cm |
| >45, < 90 | 31 cm | 33 cm |
| 90 | 31 cm | 32 cm |
| >90, <135 | 31 cm | 32 cm |
| 135 | 31 cm | 35 cm |
| >135 | 31 cm | 255 cm |
Table 2: Test of various angles from the robot to the wall.
90 degree angle
![90 angle](week4/img/angle90.jpg)
~70 degree angle
![70 angle](week4/img/angle70.jpg)
45 degree angle
![45 angle](week4/img/angle45.jpg)
From these values we see that in angles of 45 or less to the wall it's hard for the robot to detect the wall. At the same time it doesn't
seem to differ from side to side, even though there is a small distance between the 'eye' that transmits the 'ping' and the one that
receives the transmission, which could cause the robot to have a smaller range of perception in the transmitting side. This could, however,
be a possible explanation for the data showing that the robot fails to measure the distance already at 45 degrees (to the left), while
it does not fail until above 135 degrees (i.e. >45 degrees to the right). We investigated this online and found out that this guess is
most likely correct: The transmitting eye of robot builder Xander's robot is the right eye [1], which fits with our observation (we have
taken into account that Xander's photo of the robot is flipped) (http://vignette4.wikia.nocookie.net/lego/images/2/27/Ultrasonic.jpg).
### Exercise 2: Testing sample interval
In this exercise we tried to evaluate whether the sample interval of the ultrasound sensor affects the measured distances - if for instance
the last transmission returned just after a new has been transmitted reults in the robot interpreting is as a very short distance.
For this test we used the **sonicSensorTest.java** program to display the measured value on the NXT screen. Hereby we could observe if a
small sample interval would affect the measured distances.
We tried with three different sample intervals, shown in table 3, while keeping the distance constant.
| Sample interval | Sensor distance |
| ----- | ----- |
| 1 msec | 25 cm |
| 5 msec | 25 cm |
| 10 msec | 25 cm |
Table 3: Sample intervals and the resulting measurements.
We also tried with about 1 m distance, and still got approximately the same result. The only difference was, that the measured number
fluctuated faster as opposed to the original 300 ms, as we increased the distance. This can be explained by the shorter sample interval
which causes the sensor to update more often.
We conclude from this that the interval doesn't seem to have an effect on the interpreted distance, and that we can thus query the sensor
reading as often as we like. Perhaps, though, it is a good idea to average the measured distances before using them to correct the robot's
movement - at least if the sample interval is so low that the frequency of the fluctuations is higher than that of the robot's corrections.
An interesting experiment, that we unfortunately didn't do, would be to log the time of each sensor reading, and see whether the reading blocks
or is asynchroneous. This would also make us able to see the duration of a sensor reading. From our findings, we do think the readings block.
### Exercise 3: Ultrasound sensor distance limitations
Again we used the **sonicSensorTest.java** program to display the interpreted distance values.
We used the most evenly-surfaced wall we could find in the Zuse building for this exercise, as we expected that this had an effect on the
reflections of the soundwaves (also mentioned earlier). At the same time we tried to distance ourselfes from the other groups and their robots
to minimize the risk of the soundwaves from the different robots interferring with each other. We can't however be certain that the other robots
didn't affect our readings.
The result was obtained by placing the NXT on a moveable flat surface at a distance of over 255 cm. Now we slowly moved the surface closer
to the wall while observing the NXT screen for readings different from 255. As soon as we got a fluctuating number we stopped the movement
and read the display.
The obtained value was 159, which wasn't stady, but actually fluctated a lot between 159 and 255 cm. This means that in the best conditions
that we were able to produce, it wasn't possible to get a measurement of anywhere near 255 cm. We tried with other walls in the Zuse building,
but these resulted in even smaller or similar maximum distances. Therefore, this threshold of 'seeing nothing' is actually a good value
(in that it is far from the top measurement and the risk of e.g. 254 cm being reported as 'seeing nothing' is therefore irrelevant).
At the sensor's theoretical maximum measurable distance, 254 cm, the time it would take for the sound wave to travel to the wall and back to the sensor is
(2 * 2.54 m)/340.29 s = 5.08 m/340.29 s = 0.015 s = 15 ms. This means that the minimum time between sensor updates at this distance should be at least
15 ms. We however see from the LeJOS code that the sensor reading function has a mechanism, which forces a 30 ms pause between each reading, in case another one is requested
prematurely. This means that there might be a gap between the signal returning and the value being available to the robot. Thus, there usually would be no
sense in setting a sample interval lower than 30 ms, as the sensor reading would block anyways. We aren't entirely sure about how the sample interval interacts
with the sensor downtime, but our intuition tells us, that the program will wait both for the sensor downtime period and the sample interval, so if one wants
as many readings as possible, the sample interval shouldn't be set.
### Exercise 4: PID controller values
When running ***Tracker.java*** on the NXT, the robot drives straight ahead until it sees an object. It then tries to stop before hitting it. The program
does this by obtaining a measurement of the distance to the object: If the distance is smaller than the desired distance, the robot drives backwards, and
then forward again once it passes the desired distance again.
The Traker class control loop can be described as a PID-controller, as it gradualy changes its motor power based on the distance from the desired setpoint.
A PID-controller has three different values which it uses to control the entity. These are the setpoint, the process variable and the manipulated variable,
which are the disired distance from the wall, the variable we are trying to change, and the variable we are manipulating to reach the setpoint, respectively.
Specifically for Tracker class PID-controller, the setpoint is the ***desiredDistance*** variable, the process variable is the ***distance*** and the
manipulated variable is the ***power*** variable.
### Exercise 5: Experiment with PID-controllers
For this exercise we ran the ***RCparamTracker.java*** program on the NXT and the ***TrackerController.java*** on our computer. The computer program made it
possible for us to control the ***Pgain*** and ***minPower*** variables of the NXT program. What the NXT program does is to multiply ***Pgain*** with the
error distance from the desired setpoint, and then adding ***minPower***.
We tried three different combinations of ***minPower*** and ***Pgain***; (50, 1.0), (50, 10.0) and (100, 10.0).
The first combination resulted in the robot driving directly at the wall and stopping in front of it without oscillating at all. The second combination
resulted in a few more oscillations, as it valued the additional power of the distance to the setpoint higher than before which resulted in a higher overall
motor power. The last combination resulted in a constantly oscillating robot, which can be seen in the following video:
[![Oscillerende Car Tracker](http://img.youtube.com/vi/mqX0KwoueHs/0.jpg)](https://www.youtube.com/watch?v=mqX0KwoueHs)
### Exercise 6
The purpose of this exercise is to make the NXT follow the wall by placing the ultrasound sensor in an approximately 45 degree angle (see the following video).
This is to make sure that the sensor reads small values when turning towards the wall and greater values when turning away.
We tried to program a small wallfollower program (Wallfollower.java - source code can be found in repo at lego-kode/week4/Lesson2programs/Wallfollower/)
for the NXT by looking at Philippe Hurbain's NQC program [2]. We implemented a small program that
determines if the robot is in the surrounding interval of the setpoint or far from it on either side. The motors can thereby be programmed to take
more than two situations into acccount.
We struggled a lot with our program, as we couldn't get the motors to run. We eventually realized that the motor power was too low. We also ran into
some difficulties when running the program, as our left motor appears to be weaker than our right one - it runs slower, even when given the same amount of
power. However, we did get it to somewhat reasonably follow a wall, as demonstrated in the video below. The thresholds aren't finely tuned or calibrated
and they might work better if we used raw values, but for now they'll do.
[![Wall Follower](http://img.youtube.com/vi/6EavxcEhqLY/0.jpg)](https://www.youtube.com/watch?v=6EavxcEhqLY)
## Conclusion
We are not sure that we managed to keep Frej alive throughout the exercises, as his left motor seemed to be malfunctioning in the end. We did
however gather a lot of experience in regards to applying the NXT ultrasound sensor as a sensor input for NXT programs. We discovered that
despite theoretically being designed to be capable of measuring distances up to 254 cm, in reality it is infesible to get reliable values beyond
approximately 155 cm. As for the ultrasound sensors application in a Wall Follower program, we saw that the sensor has to be placed at an angle
between 45 and 90 degrees, as any angle at or below 45 degrees were unmeasurable to the sensor. We managed to implement a Java version of Philippe
Hurbain's NQC Wall Follower, and this program worked reasonably satisfactory, with the exception of our left motor seeming to malfunction slightly.
## References
[1] [http://botbench.com/blog/2011/09/21/exposed-lego-ultrasonic-sensor/]
[2] [http://www.philohome.com/wallfollower/wallfollower.htm] [Philippe Hurbain's Wall Follower]
\ No newline at end of file