- Understanding the Problem of Navigation
- Navigation Theory
- Using the Navigator API
- Creating a Navigator Robot
- TimingNavigator Accuracy
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
TimingNavigator Accuracy
The results from testing the preceding code vary greatly. After 30 seconds Trilobot is supposed to return to the point of origin, but in reality it only comes close. I performed a test by dropping a coin on the ground at the point of origin after letting the robot go. Sometimes it came back to within 50 cm, but other times it was off by as much as 90 cm! This sort of discrepancy seems hard to account for, but after performing a few experiments the reason for the inaccuracy is clear. Examine Figure 7–10. This is a small course I set up for Trilobot on carpet by placing a coin at each point. There are five individual vectors to this course, each labeled in Figure 7–10 by a number. The code to make Trilobot follow this course is as follows:
)
Figure 7–10 A test course for Trilobot.
1. import josx.platform.rcx.*;
2. import josx.robotics.*;
3.
4. class TrilobotMain {
5.
6. public static void main(String [] args) {
7. Motor.A.setPower(7);
8. Motor.C.setPower(5);
9.
10. TimingNavigator nav = new TimingNavigator(Motor.C, Motor.A, 5.475f, 4.03f);
11.
12. nav.gotoPoint(75,75);
13. nav.gotoPoint(0,150);
14. nav.gotoPoint(75, 150);
15. nav.gotoPoint(75,0);
16. nav.gotoPoint(0,0);
17. }
18. }
This looks like a relatively simple series of movements, but as you can see from Figure 7–11 Trilobot didn't handle it very well. When Trilobot executed the initial 45-degree rotation it didn't quite rotate enough—probably closer to 40 degrees than 45. Not too bad so far. Next comes Vector 2. It executes the 90-degree turn, but once again it underrotated, causing it to wander off drastically to the right. By the time it stops at what it thinks is 0, 150 the orientation of the robot is off by about 15 degrees and the x coordinate is off by about 40 cm. This vector seems to be the worst one of all five. If Vector 2 ended up at 0,150 as it was supposed to, the overall path would be much more accurate. Vectors 3, 4, and 5 are not bad, but their small errors also cause a cumulative effect on the positional estimate. The final position was off by about 15 cm from the point of origin—not bad, considering. Accuracy was probably regained because the errors in the lefthand turns were made up by countererrors in the righthand turns. So what caused all these errors?
)
Figure 7–11 Trilobot's interpretation of the course.
Errors fall into two camps by definition. Systematic errors are introduced in the design of the robot and the methodology. This includes errors due to inaccuracies in parameters used in the program and errors caused by the design of the robot itself. Nonsystematic errors are errors that are introduced because of the real world. Errors in this camp include uneven floors, wheel slippage, and cats walking in front of the robot. Let's try to identify the errors that hamper the accuracy of TimingNavigator.
Systematic Errors
The most obvious systematic error introduced into TimingNavigator is the accuracy of the travel and rotate times used in the constructor. Because the whole premise of navigation using timing relies on these, inaccuracies will cumulatively throw off the positioning. For example, the angle parameter requires the time it takes to rotate 360 degrees. If the actual rotation time is 4.2875 seconds and you give a value of 4.4425 seconds it will cause a rotation of 360 degrees to be about 12 degrees off. This disparity will add up quickly after the robot has been traveling for a time.
The biggest problem with accuracy, as we observed, was underrotation. Each time the robot attempted to rotate a discreet angle, it would consistently fall short. How can we explain this, especially after being so careful when timing a complete 360 degree rotation? For an answer we need to look to Newton's first law of motion: objects at rest tend to stay at rest. It takes a certain amount of time and force to overcome the momentum of the stationary robot. So when we tell the robot to rotate right 90 degrees it takes a small amount of time to get moving, in Trilobots case about 0.06 seconds. Because of this factor, larger angles of rotation, such as a 180 degree turn, are likely to be more accurate than smaller rotations, such as a 5-degree turn. This accounts for the observed angle being smaller than the projected angle. As with all systematic errors, it should be possible to correct this through code. Timing by hand with a stopwatch is so inaccurate it is best to start with an estimate for the delay, then refine it with a few trials. Adding the following line of code at line 11 will accomplish this:
nav.setMomentumDelay(60);
The momentum variable (which had been set to 0) will now cause the robot to delay an extra 0.06 seconds for each rotation, giving it enough time to overcome momentum. To refine this, have the robot rotate 90 degrees and stop, then note how accurate it seems. If it rotates too much, decrease this value and if it underrotates, increase the value. Now when the test course is run, accuracy should be improved.
WARNING
If you use the setMomentumDelay() method, the time variable in the Timing Navigator constructor should measure only one full rotation. Do not try to average four rotations otherwise the delay caused by momentum will be divided.
One of the biggest problems with achieving accurate parameters is that the battery slowly loses power, and thus the output speed of the motors changes. I've noticed several times that when the RCX is turned on it may have a charge of 7.6 V, and then by the time the program ends the battery power is at 7.3 V. Then, after shutting down for a few minutes, I turn it on and the voltage once again reads 7.6 V. This change really throws rotations off. The worst part is once you think you have the TimingNavigator parameters honed and the motors balanced, the battery charge lessens and the settings are no longer valid. One way to negate this effect is to use freshly charged batteries.
Nonsystematic Errors
Differences in motor speed between the A motor and the B motor also affect accuracy greatly. One of the noticeable problems encountered in the course just presented is the inability of the robot to drive straight. Just when I thought I had the motors balanced it would start drifting to the right. Then, later in the same run, it would mysteriously straighten up for some stretches! This effect can be attributed to frictional differences in the structure of the robot.
A comparatively minor source of errors likely results from the surface the robot is on. Carpet and rough surfaces are likely to introduce more errors than a smooth floor such as hardwood.
Contact with external objects also introduces error into the positional estimate. When the bumper hits an object it has the potential to turn the robot slightly out of alignment. This can be minimized by slowing down the robot, or by detecting objects before the robot strikes them using a proximity detector (see Chapter 9, "Proximity Detection").