Internal operations on the robot

General observations:
The class which resides on the NXT is responsible for the methods that interact directly with the motors and sensors. That is; reading, writing and moving. These methods have been implemented in the class Robot.java.

Basically, since the light sensor is positioned above the black track markers on the left side of the track, we use it to detect changes in light intensity, which tells us that it has moved from one black square to a space between squares. The move method turns on the motor and drives forwards as long as no change in intensity is detected.

The reader arm is five intensity changes away from the writer claw, so some maneuvering is required between reading and writing.

When the read method is called, the robot swings the read arm down to read the first bit, then moves two intensity-changes (one bit) forwards and reads the next. When it is done, it resets its position over the bit.

The writer operates in similar fashion, save that it swings back and forth across the track depending on the type of bit that needs to be set.

Since the move method keeps the motor on until there is a intensity change in the light sensors reading, it is built upon reactive control. We have not used an approach where we observe several readings before judging whether or not an intensity change has occurred. The observations of this straight forward implementation gives a solid picture that the robots behavior is indeed correct.

The model of movement is quite solid, even though that we are not positioned directly above the bit when we have to make a reading. When the read head is extended, it only touches the LEGO bits by half of its surface, as can be seen in the videos posted.

The amount of movement required to read/write was experimentally established previously.

Test process
The read/write mechanism, has been tested locally on the NXT by making a simple test method in the robot class that is called on execution. Here, we hardcode the transition function by simple calls to read, write, and move.

Duration of activity: 2hrs
Group members participating: Mikkel, Martin, Anders, Sean

First experiment:
Goal:
Testing the read mechanism.

Experiment:
We started testing the read method, by doing iterated tests on the cellSize. At each iteration, we gathered information on the correctness on the value read, the movement between individual bits and the movement back to the least significant bit (the start position of a given cell). We also tested that the conversion from bits to integers was indeed correct.

Results:
During the testing of the read mechanism, the touch sensors gave us a bit of a problem. How long do we have to rotate the motor, and what cell position equals one and vice versa. Earlier we tested the rotation of the motor with a Bluetooth connection. When the touch sensors extend, they have to be able to read the correct position of the bit. The problem was, that we had not come up with a convention that says which positions equals what. This is discussed in a previous blog entry.

To avoid the same mistake again, we chose to use sounds and the LCD display to play/display output during a test run.

Second experiment:
Goal:
The write method was tested in the same way. The primary differences are, that we need to convert from integers to bits, which is a little bit different than making the conversion the other way around, and that the rotation of the motor has to be more precise.

Experiment:
We have made the write method be responsible for checking that we do not write the same value as the last read value, and that we do not try to move a bit to the same position as it is in. At present, to test the first functionality, we manually have to set the input tape to a given value and then try to write the same integer.

The second case also requires that the tape has been set manually. It is a success if the robot "skips" the bits that do not have to be moved.

Results:
The write arm functions as expected, no further observations made.

Conclusion of the tests:
In testing the above we have found that it is sometimes difficult to determine when the Turing Machine fails and why.
We have been thinking about making the Turing Machine a little bit more responsive the value it reads and writes to the tape. To achieve that, we have had a look at the Sound.java class which have the functionality we are looking for. At the moment, if the robot reads a bit with value 1, it plays a positive beep sequence. On the other hand, if it reads a zero, it plays a sad sound. This information is also a good supplement in debugging, since we know what the robot reads and writes.