|
|
test
|
|
# Group 8
|
|
|
|
|
|
|
|
<img src="../raw/master/lesson2/Pictures/UltraSonicSensor.jpg" width="200" height="200" />
|
|
## Lab Notebook 2
|
|
|
|
|
|
|
|
[[ https://gitlab.au.dk/lego-group-8/lego/tree/master/lesson2/Pictures/UltraSonicSensor.jpg | height = 100px ]]
|
|
**Date:** 19/2-2015
|
|
|
|
|
|
|
|
 |
|
**Duration:** 8-10 hours
|
|
\ No newline at end of file |
|
|
|
|
|
**Participants:**
|
|
|
|
|
|
|
|
- Frederik Jerløv
|
|
|
|
- Casper Christensen
|
|
|
|
- Mark Sejr Gottenborg
|
|
|
|
- Peder Detlefsen
|
|
|
|
|
|
|
|
## Goal
|
|
|
|
The goal is to equip our NXT Robot with a ultrasonic sensor and execute the exercises.
|
|
|
|
|
|
|
|
See more [1].
|
|
|
|
|
|
|
|
## Plan
|
|
|
|
Our plan is to follow the exercises exactly as described.
|
|
|
|
|
|
|
|
## Results
|
|
|
|
|
|
|
|
### Exercise 1
|
|
|
|
The goal of this exercise was to measure the distance of some different objects. We measured the distance of three different objects (cardboard, trashcan and ink patron) on a table with a ruler, and marked the distances in 5 cm intervals on some tape. The result is displayed on the diagrams below:
|
|
|
|
|
|
|
|
|
|
|
|
> Blue is cardboard, Red is trashcan, Yellow is ink patron
|
|
|
|
> X-axis shows our measurements on the table
|
|
|
|
> Y-axis shows the different from the NXT and out measurements
|
|
|
|
|
|
|
|
The cardboard and trashcan differs around 1 to 2 cm. This is ok a ok result since we properly did not get the robot to start at exactly 0 cm. Same problem with the object not being set exactly on the measured mark. The cardboard has a spike with 4 cm in difference, maybe we did not hold it orthogonal to the table. The NXT measured the trashcan closer than it was. The reason was that the trashcan was wider at the top (see picture below).
|
|
|
|
|
|
|
|
|
|
|
|
> Setup of a measurement of trashcan
|
|
|
|
|
|
|
|
Ink problems
|
|
|
|
We experienced problems with an ink ""patron"" at a distance of 120 cm. It hits the bumps on the front of the catridge as seen on Figure and the sound goes of into another direction. Which result in the "ping" not returning.
|
|
|
|
|
|
|
|
[Figure - Inkpatron](http://i.imgur.com/sAR8ELR.jpg)[2]
|
|
|
|
|
|
|
|
### Exercise 2
|
|
|
|
A smaller amount of sleeping seems to update distance faster. This makes sense.
|
|
|
|
|
|
|
|
It always takes 35 ms to call getDistance. If you make the program sleep for 30+ ms the getDistance call will take 5 ms to return. Decreasing the amount of sleep below 30 ms will make getDistance take up to 35 ms. This matches the delay values in the UltrasonicSensor class where DELAY_DATA_OTHER = 30 and DELAY_CMD = 5.
|
|
|
|
|
|
|
|
This shows us that the NXT continually fetches data each 30 ms, even while the program sleeps, and getting the data have a delay of 5 ms. Because of this the optimum amount of sleep before is subsequent getDistance call is 30 ms.
|
|
|
|
|
|
|
|
### Exercise 3
|
|
|
|
It is possible to measure a distance of 254 cm when placing the NXT on the floor 254 cm away from a large wooden box with a smooth uniform surface.
|
|
|
|
|
|
|
|
We tried on another surface (light grey) but there were no problems.
|
|
|
|
|
|
|
|
It requires a surface which is orthogonal with the sensor.
|
|
|
|
|
|
|
|
On an upwards angled wall the NXT could not measure beyond 101 cm and using a large plant container the limit was 175 cm.
|
|
|
|
|
|
|
|
Using the speed of sound (340,29 m/s) and the max distance of 255 cm we can calculate the time limit of the sensor:
|
|
|
|
|
|
|
|
2,55 m * 2 / 340,29 m/s = 0,015 ms
|
|
|
|
|
|
|
|
This is half of the delay leJOS has built into the getDistance function.
|
|
|
|
|
|
|
|
Does this limit the usage of the sensor???
|
|
|
|
|
|
|
|
### Exercise 4
|
|
|
|
The behaviour of the car is defined like this:
|
|
|
|
The car will continually check for object within range of the sensor (255 cm). If an object is seen the car will move forward if the object is further away than the desired distance of 35 cm. Should the object be closer than 35 cm the car will move backwards until it reaches the desired distance.
|
|
|
|
|
|
|
|
The Tracker uses a PID controller in the control loop. Such a controller is defined by calculating an error value as the difference of a setpoint and a measured process variable. It then uses a manipulated variable to reduce the error.
|
|
|
|
The setpoint is the desired value of 35 cm stored in desiredDistance. The process variable is the measured distance to the object stored in distance. Finally the manipulated variable is stored as power as two times the error capped at maxPower.
|
|
|
|
|
|
|
|
|
|
|
|
### Exercise 5
|
|
|
|
For this exercise we have experimented with the TrackerController program to adjust the values of minPower and Gain. The variable minPower holds the minimum power of the motors where 0 is no power and 100 is maximum power. Setting this to 100 will force the car to always run at top speed making it sprint backwards and forwards to stay at the desired distance. The other variable called Gain is multiplied with the calculated error to get the needed correction. If this variable is set to 10 or more the car will again oscillate at top speed.
|
|
|
|
|
|
|
|
Here’s a [video demonstration](https://vimeo.com/120279261)[3].
|
|
|
|
|
|
|
|
### Exercise 6
|
|
|
|
In this exercise the goal was to make a wall follower robot based on a program by Philippe Hurbain[4]. To to this we first had to mount an ultrasonic sensor on top of our robot and point to the side in a 45 degree angle. This makes it possible for the robot to determine whether it is getting closer to or further away from the wall.
|
|
|
|
|
|
|
|
|
|
|
|
> A picture showing the ultrasonic sensor mounted on our robot.
|
|
|
|
|
|
|
|
We made a program based on the NQC program while adding some features of our own. Hurbain is using a number of if statements to decide the robots behaviour at different distances. We are using the same structure but with our own distance thresholds which were found by experimentation. This structure gives our robot six different states with variable motor settings.
|
|
|
|
|
|
|
|
Hurbain was using all 4 motor modes (forward, backward, stop float) but we ended up using only forward and backward. The reason for not using the stop mode was it would make the robot turn too aggressively if one wheel brakes and the other turns. The float mode was ineffective as the resistance on the wheel were too great for it to actually float which then gave us too sharp turns. Instead of those modes we modified the power for each motor in every state which then gave us the ability to make smoother turns when correcting the distance to the wall. Five of our states are very similar since they just reduce the power of the motor pointing in the direction we want to turn. The state reached when the distance is ‘wayTooClose’ is different because it does a right turn in place to get out of a corner.
|
|
|
|
|
|
|
|
The important code part is shown below:
|
|
|
|
|
|
|
|
```java
|
|
|
|
while ( running ) {
|
|
|
|
distance = us.getDistance();
|
|
|
|
diff = x - distance;
|
|
|
|
x = distance;
|
|
|
|
motorLeft = Car.forward;
|
|
|
|
motorRight = Car.forward;
|
|
|
|
powerLeft = powerRight = 75;
|
|
|
|
if (x <= littleTooClose) { // Close to the wall
|
|
|
|
if (x <= wayTooClose) {
|
|
|
|
motorRight = Car.backward;
|
|
|
|
powerLeft = 65;
|
|
|
|
powerRight = 65;
|
|
|
|
} else if (x <= tooClose) {
|
|
|
|
powerRight = 55;
|
|
|
|
} else if (x <= littleTooClose) {
|
|
|
|
powerRight = 65;
|
|
|
|
}
|
|
|
|
} else { // Far from the wall
|
|
|
|
if (x >= wayTooFar) {
|
|
|
|
powerLeft = 55;
|
|
|
|
} else if (x >= tooFar) {
|
|
|
|
powerLeft = 60;
|
|
|
|
} else if (x >= littleTooFar) {
|
|
|
|
powerLeft = 65;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
Car.controlLeft(powerLeft, motorLeft);
|
|
|
|
Car.controlRight(powerRight, motorRight);
|
|
|
|
|
|
|
|
//Delay.msDelay(sampleInterval);
|
|
|
|
}
|
|
|
|
```
|
|
|
|
The rest of the code can be found [here](https://gitlab.au.dk/lego-group-8/lego/tree/master/lesson2/WallFollower)[5].
|
|
|
|
|
|
|
|
A demonstration of the NXT following a wall can be seen in [this video](http://1drv.ms/1Goiheq)[6].
|
|
|
|
|
|
|
|
As we can see in the video it keeps itself at a good distance from the wall while moving straight forward. It does a good job turning around corners and obstacles. When we get to a 90 degree wall turn it stops and turns in place and start getting back to the preferred distance. This happens in a slowly manner because it changes a lot between the states.
|
|
|
|
|
|
|
|
## Conclusion
|
|
|
|
We equipped our LEGO car with a ultrasonic sensor and we compiled and uploaded a program (SonicSensorTest.java) to test the measured distanced from the sensor and compared it with our measurement from a ruler.
|
|
|
|
|
|
|
|
Inspired from a program by Philippe Hurbain[3]. We implemented our own WallFollower which worked quite well (see Exercise 6 for more).
|
|
|
|
|
|
|
|
## References
|
|
|
|
[1] [Exercise material](http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson2.dir/Lesson.html)
|
|
|
|
[2] [Figure - Inkpatron](http://i.imgur.com/sAR8ELR.jpg)
|
|
|
|
[3] [TrackerController video demonstration](https://vimeo.com/120279261)
|
|
|
|
[4] [Philippe Hurbain, WallFollower](http://www.philohome.com/wallfollower/wallfollower.htm)
|
|
|
|
[5] [Wall follower video demostration](http://1drv.ms/1Goiheq)
|
|
|
|
[6] [Wall follower code](https://gitlab.au.dk/lego-group-8/lego/tree/master/lesson2/WallFollower) |
