Design. BE 1200 Winter 2012 Quiz 6/7 Line Following Program Garan Marlatt

Transcription

1 Design My initial concept was to start with the Linebot configuration but with two light sensors positioned in front, on either side of the line, monitoring reflected light levels. A third light sensor, facing forward and working in combination with the RCX s infra-red messaging system, would act as a proximity sensor for obstacle detection. The program would respond when either or both of the path detecting sensors registered a drop in light levels, indicating that the robot was beginning to cross the line. At the same time the proximity sensor would monitor reflected infra-red light levels to detect imminent collision. The first decision I made was to write a program tailored to the specific requirements of the track, rather than writing a program that could handle a wider variety of tack configurations. This would make my program less useful for future projects but generally easier to write. One potential drawback to this approach was that if the robot encountered a situation outside its programmed responses, it would lose control. Naturally, that happened quite often in the early stages of writing the program. To create the program I first divided the problem into smaller, task-specific modules: 1) Follow a straight line, 2) Recognize the intersection, 3) Make a right turn, 4) Recognize the obstacle, 5) Make a 180 degree turn, 6) Recognize the green patch. I then wrote and tested each module individually which greatly simplified the debugging process and reduced the amount of time required to code the project (saved batteries, too). When each of the parts was working, all that remained was to put them together and work out any conflicts. 1st Implementation: - One function to set up sensors - Two functions written to handle minor course corrections and the intersection turn - One task to constantly broadcast an IR message - One task to constantly look for the green patch - One task with a decision tree to constantly monitor sensor levels and call appropriate navigation functions - Main task that calls set up function, configures motors, starts and stops all tasks I tried to set up an EVENT for the proximity sensor but was never able to get it to work. I gave up pretty quickly because of scant documentation and resorted, instead, to IF statements. When tested independently, the messaging and proximity sensor worked fine, but in the main body of the

2 program they didn t play nice. Because of time constraints, I gave up on the idea of using the IR messaging system and made the proximity sensor a simple light sensor. The relatively weaker light source of the sensor meant that the robot would have to approach the obstacle much closer in order to detect it. 2 nd Implementation: - One function to set up sensors remained unchanged - Two functions to handle minor course corrections and the intersection turn remained unchanged - One task to constantly look for the green patch - One task with a decision tree to constantly monitor sensor levels and call appropriate navigation function now included a check for the proximity sensor - Main task that calls set up function, configures motors, starts and stops all tasks This implementation displayed erratic behavior and after a lot of tinkering, I decided to turn the TASKS into FUNCTIONS that looped sequentially, abandoning the multitasking technique that multiple running TASKS use. This resulted in a program that reacted predictably and consistently, even though the robot did not perform correctly. 3 rd Implementation - One function to set up sensors remained unchanged - Two functions to handle minor course corrections and the intersection turn remained unchanged - One function added to make 180 degree turn after encountering obstacle (original program ran robot in reverse), to meet assignment requirements - One function checking light sensors for green patch - One function checking proximity sensor for presence of obstacle - One function with a decision tree checks sensor levels and calls appropriate navigation functions - Main task that calls set up function, configures motors, runs conditional WHILE loop for three functions checking sensors This is the structure of the final program. From this point on, most of the work was just tweaking the code.

3 Challenges Track condition and illumination levels: One of the first things I did was to build my own test track modeled on the track we used in class. This was an immense help as it allowed me to test my programming outside of class, as time was available. I took the RCX brick and a light sensor to the store to get green and pink materials that closely matched the sensor values obtained from the track in class. Of course, because my track was made of new materials, it did not exhibit the wear and tear of the in-class track. The new track had much less variation in reflectivity within each color and a higher contrast between the white, black, green and pink values. Consequently, when I first ran my robot on the class track, it had difficulty distinguishing between a white white and a gray white, a matte black and a shiny black, and it saw green as anything except green! To deal with this situation, I put my light sensors in RAW mode to provide finer gradations of measurement and incorporated value ranges in my evaluation code, i.e., green_value-10 and green_value+20. My conditional statements then took this form: if ( (SENSOR_1 >= green_value 10) && (SENSOR_1 <= green_value + 20) ) If the green_value = 687, for example, then the conditional tests for 677 <= SENSOR_1 <= 707. By carefully adjusting the range values, it became fairly easy to find green. Any variations in ambient light levels also proved to be a challenge to my code. Because I decided to record a specific white value at the start of the track and compare my light sensor readings to that, any significant variation along the course could exceed my range values. A heavy shadow, a ray of sunlight, or even a strong light source nearer to one end of the track than the other could potentially defeat the program. The track needs to be evenly illuminated for my program to successfully guide the robot. I considered having the program periodically resample the reference white values during the run so that the readings from the light sensors wouldn t fall out of my preset range, but the conditions in the classroom were close enough to ideal that this wasn t necessary. Mechanically, to minimize ambient light effects, I placed the sensors very close to the surface of the track and the body of the robot so that the surface area reflecting light into the sensors was minimized and shaded from external light sources. This also maximized tracking accuracy and made maneuvering more reliable. I thought about building a hood to shade the sensors from ambient light, but this degree of mitigation wasn t necessary.

4 While wrestling with these issues, it became apparent that a better approach would have been to use a single light sensor and a scan, sample, and compare program to always steer the robot in the direction of the lowest light level reading. A black-seeking algorithm would avoid most of the complications of my black-avoiding algorithm: fewer sensors to manage, no reference values needed, variations in light levels automatically handled, etc. Lesson learned. Timing, speed, power: I observed that if the robot s motors are run at full speed, the program occasionally failed to react when a sensor passed over a line. This could be due to the sensor reading lying outside of my value range and/or it could happen if the program was busy doing something other than checking the sensors while the robot passed over the line. I had already used the suggested Linebot gear reduction (16-tooth on motor, 24-tooth on hub), so I reduced power to the motors, diminishing the robot s speed and allowing the sensors to remain over the lines for more time. This worked great. The gear reduction allowed the motors to run at a higher power level (needed to drive the tank treads) but moving the robot at a slower speed. This meant that I could slow the motors without sacrificing maneuverability. Software: I had difficulty running multiple, simultaneous, tasks especially if there was any interaction between them. I don t have a clear understanding of how the multitasking works or what its limitations are. Because of time limitations, I couldn t really explore and experiment to see if I could resolve my issues, but using sequential function loops instead worked fine for this program. There also appears to be a limit to the allowed complexity of compound conditional statements. The following code wouldn t work: if (((LEFTEYE >= left_green-5) && (LEFTEYE <= left_green+5)) && ((RIGHTEYE >= right_green-5) && (RIGHTEYE <= right_green+5))) { } I had to break that down into separate statements to get it to work. While conditionals with a single logical AND work fine, I used my testing/debugging version consisting of four separate statements. Useful Practices 1) Pre-code by setting up a flow chart so there is a plan to follow when writing code. 2) Keep code modular; use tasks, functions, macros: easier to follow and debug. 3) Put lots of comments in your code so it is easy to tell what is supposed to be happening.

5 4) Keep your code orderly and structured it s easier to find errors. 5) Be careful if using while(true) loops the code is always running. 6) Write a tiny program that configures your outputs and turns your motors: OnFwd use it after you change batteries, modify your robot, or your program makes the robot run in unexpected directions. 7) Follow the KISS principle.