... | @@ -158,4 +158,22 @@ Fig. 3 - Code from our custom java version of Philippe's NQC program. |
... | @@ -158,4 +158,22 @@ Fig. 3 - Code from our custom java version of Philippe's NQC program. |
|
|
|
|
|
We expected the desired distance to the wall to be between 50 and 55 cm. If the robot moves too close three if statements will make corrections accordingly. The same applies if the robot moves too far away from the wall where two if statements are ready to move it closer.
|
|
We expected the desired distance to the wall to be between 50 and 55 cm. If the robot moves too close three if statements will make corrections accordingly. The same applies if the robot moves too far away from the wall where two if statements are ready to move it closer.
|
|
|
|
|
|
We tested our implementation of the program by making the robot run a simple course (see fig 4). A video of the run can be seen here: https://drive.google.com/open?id=0B4Vn_sxU595gbVhnUFVyWmlyaFE&authuser=0 |
|
We tested our implementation of the program by making the robot run a simple course (see fig 4). A video of the run can be seen here: https://drive.google.com/open?id=0B4Vn_sxU595gbVhnUFVyWmlyaFE&authuser=0
|
|
\ No newline at end of file |
|
|
|
|
|
![Skærmbillede 2015-02-26 kl. 16.10.13](http://gitlab.au.dk/uploads/group-22/lego/72679eb42c/Sk%C3%A6rmbillede_2015-02-26_kl._16.10.13.png)
|
|
|
|
Fig. 4 - Simple track to test wall follower program.
|
|
|
|
|
|
|
|
**Results:**
|
|
|
|
Looking at graph below we can see that our intended distance of between 50 and 55 cm did not hold true. The robot turned towards the wall until it reached a distance of around 25-30 cm and then oscillated around that distance.
|
|
|
|
|
|
|
|
![Skærmbillede 2015-02-26 kl. 16.13.00](http://gitlab.au.dk/uploads/group-22/lego/a8413d069c/Sk%C3%A6rmbillede_2015-02-26_kl._16.13.00.png)
|
|
|
|
Fig. 5 - Distance measurements of run. x-axis: time in ms. y-axis: distance cm.
|
|
|
|
|
|
|
|
As can be seen in Fig. 5, the graph shows a lot of readings of 255 cm. This means the sensor is not detecting any objects, but does not necessarily mean that the robot is 255 cm away. In a perfect program this problem should be considered and the anomalies sorted out. Between 5000 and 7000 ms, we can clearly see a large number of 255 cm readings. This is where it actually turns the open, outwards 90 degree corner, where there are two in a row, as can also be seen in the lower left corner of Fig. 6.
|
|
|
|
|
|
|
|
We also encountered another issue with an inwards 90 degree corner as can be seen in Fig. 6. When the robot measures the distance to the upcoming wall, it turns as expected because the distance is quite short. It then turns to the right, but now measures the new distance to the wall and finds that the distance is now quite long (more than 25-30 cm), so it decides to turn back and sees the short distance to the closer wall again. After about 5-10 turns the robot somehow moves on. We suspect that one of the 255cm error/anomaly readings actually got the robot to turn a bit further to the left so it could get a proper reading and actually manage to continue its route.
|
|
|
|
|
|
|
|
![Corner trouble](http://gitlab.au.dk/uploads/group-22/lego/66ecfa47a7/Corner_trouble.png)
|
|
|
|
Fig. 6 - corner issue.
|
|
|
|
|
|
|
|
Comparing Phillippe’s program to the Handybug program, a key difference is that the Handybug only handles two different cases: too far from the wall turn in, too close turn out. This means that the car will not drive in a straight line, but zigzag along the wall. Philippe’s program uses more thresholds to control the steering, resulting in a more smooth path along the wall. |
|
|
|
\ No newline at end of file |