NXT Programming - Lesson 9

---

Date: 15.11.2007
Duration of activity: 4 hours
List of participants: Alessandro, Samuele

---

Goal of the days: Investigate how a Lego NXT robot can keep track of its position and navigate avoiding the obstacles

First plan:

1. measure the physical characteristics of the robot
2. get used to the Navigator classes
3. think a way of measuring errors
4. write the test program
5. measure Navigator's accuracy

1. We used the same robot of the previous lab session: we just made little changes like removing the light sensors. This choice will turn out as a bad choice...
   
   wheel diameter:
   4.32 cm (as written on the tires)
   wheel distance:
   17.7 cm (measured with a plastic ruler - precision = ± 0.1 cm)


2. We copied the Blightbot main program to see if the parameters are correctly passed, and if the overall behaviour seems to be correct: it didn't, we had serious movement issues.
   First of all we had to get strongly fixed the position of the motors, which would make the wheel distance be inaccurate.
   
   Then we avoided that Lego pieces, other than the wheels, touched the ground and modified the precision of the robot movements.
   
   We tested the robot again to follow the same path as the original Blightbot:
   0,0
   100,0
   50,50
   50,-25
   0,0
   
   We had friction problems with the tape on the ground. When the robot drives over it, sometimes a motor loses contact with the floor, and the robot rotates of many degrees.
   
   Positions after three consecutive runs of the algorithm
   start:
   
   end:
   
   
   We also tried to remove all unnecessary stuff, to make it more stable.
   We passed to the next step anyway, to quantify the error more precisely.


3. Rotation accuracy quantification
   In order to amplify the angle error, after a rotation, we made the robot go far (10 meters), rotate 180 degrees and then come back.
   Then, the distance from the start and end point is proportional to the error angle

Nice try, but the error is in the order of ten degrees, so this test is not appropriate, we had to try a completely different approach.

New tests:
Naive test with a single 360° rotation
start

end


New rotation quantification algorithm
Simply rotate in place of 360°, and estimate the error angle.
A way to measure such a big angle is to make the robot continuously rotate of pi, and count at which iteration of this rotation it becomes aligned again, i.e. among how many iterations it loses 180°.
We added a light sensor, calibrated on a small white paper stripe, and added a control that makes the robot stop rotating of 180° when it sees again the stripe.

We found then an interesting result: at first rotations, the robot lost many degrees per rotation. Then, it precision became higher, probably because the dust that made the robot lose friction was gone after some rotations.
After 87 rotations the robot became aligned again, i.e. it made 86 180° real rotations in 87 "software" rotations.
Effective rotation: x = 180*86/87 = 177.93°
Mean rotation error: e = 180-177.93 = 2.07°

We couldn't think of a test for distance, without a ruler, since if the robot loses an amount of distance proportional to the travelled distance, every geometric shape you can think is uniformly scaled. And if it doesn't, it's even worse without a ruler.

We decided to go on with the lab session, and see if this loss of precision sensibly affects the overall behaviour of a navigator robot.

Goal:
Write an algorithm that can make drive the robot from one point to another, and avoid obstacles if any.

We wanted to use the lejos Navigator classes, and in order to do so, every robot movement must be made through that interface, otherwise it would have lost track of its position at each encountered obstacle.
We decided the following strategy: make the robot go toward the goal position, if there is no near obstacle, and whenever one is found, make it go left or right to avoid it, and then make it go again toward the goal position.

pseudocode:

while not on goal {
 sample distance ahead
 if (obstacle) {
  avoid
 }
 else {
  go to goal
 }
}

Translating into java code we couldn't use the goTo method, since it doesn't support the returnImmediately flag, so we used this little trick instead:

navigator.rotateTo(navigator.angleTo(x,y));
navigator.travel(navigator.distanceTo(x,y), true);

Then, we had to force the navigator class to update its position, because whenever we called the stop method while the robot was moving, its position was lost.

Avoid strategy:

rotate 90°
if(obstacle)
rotate 180°
if(obstacle)
 beep //stuck in an angle
 return
drive 20cm

The algorithm worked well, avoiding a single small or big obstacle to get to the goal point.

However, the navigator precision is affected by how many rotation it does, i.e. the number of obstacles it encounters on the way.
The algorithm could probably have worked even with a goal in a different room, making the robot find the door (if the door is on the right, actually), but after some rotations, the robot completely loses track of its position, and the robot randomly wanders.