Objectives
1. To program a robot to drive 2m in a straight line
2. To program a robot to move in a closed shape
3. To program a robot to perform a task using 2 sensors
Figure 1 - My Robot
To program a robot to drive 2m in a straight line
Approach
This task required one to use both the NXT Visual Programming Language and RobotC language to write a program that would get a robot to move 2 meters in a straight line. My initial idea was to keep the power level of my robot’s motors at a constant level e.g. 70, and then get the robot to move for a number of seconds. After that, I’d measure the distance travelled by the robot in order to find the speed. With the calculated speed and the known distance of 2 meters, the following formula:
would be used to calculate how long the robot needed to move in order to cover the distance of 2 meters. Another way to go about this task is to measure the radii of my robot’s wheels, in order to find the circumference of the wheels. One revolution made by the wheels would mean that the robot had travelled a distance equal to the circumference of its wheels. By dividing the distance of 2 meters by the circumference, one would get the number of revolutions the robot’s wheels must make to travel a distance of 2 meters. Just as in the other approach, the power level of the motors must be kept constant.
I chose to use the second approach. With a wheel radius of 2.8 cm, the circumference was calculated as:
The number of revolutions to be made was calculated as:
Implementation using NXT
Writing the program using the NXT language was straightforward. I set the motors to move forward and input the calculated number of revolutions in the duration (rotations) field. One problem, however, was the number of decimal places one could enter into duration field. I noticed that the limit was 3. This is probably due to the accuracy of the NXT software that handles the encoder for the wheels. Left with no other choice, I rounded up the figure for the number of revolutions to 11.368 instead of 11.369 because the former was closer to the desired figure.
Implementation using RobotC
The implementation was also straightforward using RobotC. I used the nMotorEncoder function, which enables one to specify the number of degrees/rotations the wheel should make. In RobotC, however, I was able to use the whole figure for the number of rotations without rounding up.
Results of Tests
I ran the program for both languages 5 times each on a tiled floor and took some readings. The 5th try was on a different surface – a terrazzo floor.
When the average error (excluding the 5th try) is computed for both languages, one can see that the average error for NXT (0.000625) is slightly larger than that for RobotC (0.000375), although both are quite small. This may be explained by the inability of the NXT language to accommodate the full number of decimal places of the calculated value for rotation. It is safe to say that the theoretical/calculated value for rotations works in practice because of how small the error is. The run on a different surfaced floor (the terrazzo) was not too different from the figures obtained when the floor was a tiled one. This is because the program used the number of rotations to measure distance instead of time.
Figure 2 - Robot at end of 2 meters (tiled floor)
Figure 3 - Robot at end of 2m on terrazzo
To program a robot to drive in a closed shape
Approach
This task required us to use both languages to program a robot to move in a closed shape. My chosen shape was a four-sided figure, a square. The angles between the various edges of a square are 90 degrees each. My approach was to get the robot to move a distance, d meters, in a straight line, stop, turn 90 degrees anticlockwise, move d meters, stop, turn 90 degrees anticlockwise, move d meters, stop, turn 90 degrees anticlockwise, move d meters, stop, and finally, turn 90 degrees anticlockwise. This should produce a square. In order to get the robot to turn about the inner wheel, the inner wheel had to cease while the outer wheel moved.
Implementation using NXT
Writing the program was straightforward. I had two blocks in a loop block. The loop block repeated the blocks within it for 4 times, representing the four sides of the square. The inner blocks consisted of one that made the robot move in a straight line and another that caused the rotation. I had to keep adjusting the degrees the wheel should turn before coming close to the 90-degree rotation I needed. This is probably because of the speed at which my motors were moving.
Implementation using RobotC
Writing the program using RobotC was more difficult than using NXT. In NXT, I could specify angles, however, in RobotC, the implementation was different. I had to specify the individual motor power levels and a waiting time during which the previous command kept running.
From the code above, motor C is run at 30% power level and motor B is turned off. This continues for 1230 milliseconds causing the robot to spin about wheel B. The difficulty here was finding the exact duration needed for a 90-degree turn. I kept tweaking the figure and testing until I got a turn as close as possible to 90 degrees.
Results of Tests
I ran the program for both languages 4 times each and took some readings.
From the results, NXT was more accurate in getting back to its starting position. This is because most of the calculations one has to make are hidden from the programmer unlike in RobotC, where one is responsible for figuring out how to get the exact angles one wants.
To program a robot to perform a task using 2 sensors
Approach and Implementation
I used the NXT visual language for this task. I used the sound sensor and the ultrasound sensor. The implementation was fairly simple. I wanted my robot to begin to begin to move when the sound in the room exceeded 60 dB. If the robot approaches an object that is less thatn 30 cm away, it should stop, reverse and change direction. I implemented these using the sound block, distance block, and motor blocks.
Conclusion
I found this task fun and educational. I observed that the NXT visual language was easier to use than the RobotC for this particular task. This is because one did not have to consider a lot of variable when using NXT. A lot of the complicated parts are hidden from the programmer unlike in the case of RobotC. However, I noticed that Robot can be more accurate than NXT, if mastered. RobotC made it possible to use values with more decimal places and hence was more precise unlike NXT, which rounded off numbers. Another observation I made was that the robots did not consistently produce the same behavior when I ran them, although, very close.
Ashesi Robotics 