Milestone 4 Report

INTRODUCTION

The objectives of the 4th milestone were to add sensors and code to the robot to accomplish both the flashlight corridor and pinbot corridor tasks. The specific hardware needed was some kind of bumper switch on the front of the robot to detect when it had hit something and some kind of light detecting sensor on the front as well.

We decided to use a photocell for the light detection because they had worked well for detecting incandescent light in milestone 3. The sensor was mounted at the height the light was on the board, and would be used to detect the light that turned on when the pinbot bumper was hit. The bumper that was added to the front of our robot was basically a flat piece of plastic stood on its side and mounted on two spring-loaded pistons so it would move in when pushed and move back out when no pressure was applied to it. A roller lever switch was mounted directly behind the plastic so it would be activated when the bumper was pushed in. The switch was connected to a general I/O pin on port C of the micro controller board. With this assembly we could detect when the robot had run into something in front of it (e.g. the pinbot bumper). Supplementing these hardware additions were new software “functions” to handle the new tasks as well as a change in the overall structure of behavior-controlling code.

ROBOT CONFIGURATION

Electrical Configuration

The electrical configuration of this milestone was very simple given our experience from previous milestones and probably only took us a total of 1 hour.

Parts Used:

The single photocell was connected exactly the same as those in milestone 3, with the photocell being powered by +5 volts from the DC power regulator and with the 640 ohm resistor biasing the reading that was connected to the A/D converter on Port E of the FORTH board. The sensitivity of the photocell was then measured using a voltmeter. It was found that ambient light induced a voltage of about 0.4 volts and the incandescent light above the pinbot bumpers induced a voltage of about 1.7 volts. This was an adequate spread for us to detect whether the light was on or not. We set our decision threshold to about 1.3 volts and that has worked nicely.

Connecting the switch was straight forward. Basically the switch connects one lead to another when the switch is “off” and the same lead to a third when it is “on”. Using a voltmeter, we determined which leads were connected to the common one when the switch was on and when it was off. We connected the “off” one to ground and the “on” one to +5 volts. Then we connected the common lead to a general I/O pin (#1) on port C. This way portC1 would read a 1 when the switch was activated and a 0 when the switch wasn’t. By polling portC1 we could determine whether the bumper was depressed.

Mechanical Configuration

The photocell was physically mounted exactly the same as the side mounted photocells for milestone 3, except it was mounted on the front/center of the robot facing forward. The photocell was inserted into some black plastic tubing to provide some side blinding and then was glued to a piece of perforated plastic board. The board was then screwed to a metal mount and attached to the top platform of the robot. See the image on the right.

The bumper was constructed from a flat, approximately 2”x7” piece of gray PVC(?) perforated plastic. This plastic was stood on its side and mounted to two spring loaded pistons that could move in and out of two metal mounts they were attached to. Because the pistons would not always be pushed exactly perpendicular to the angle of the mount, the shafts were greased to prevent binding. The mounts were then attached to the main robot platform so the bottom of the bumper was about 2” from the ground. The roller lever switch was mounted directly behind the bumper so that it would be activated when the bumper was depressed more than 1/4”. 

 

 

Sensor to Actuation Mapping

The Flashlight Corridor

The code we wrote for the flashlight corridor was simply an extension of the code we had written for the light channel. It basically polled the right photocell to see if it had seen light. The data collected from the photocell was dual thresholded: this means the software would not acknowledge a “seen light” until the voltage read from the photocell was above a high threshold, and once above that high threshold, the software would not acknowledge the light was off until the voltage reading was below a low threshold. This allows the code to ignore low degree localized noise from the sensor and just deal with the general trend. After we had applied a long blinder to our right photocell, we could determine the high and low thresholds we needed with a voltmeter. A correct high threshold would be lower than the voltage reading when the photocell was directly in front of the light and a correct low threshold would be higher than the voltage reading when the photocell was exactly between the lights. Once these thresholds were determined, we never had to change them; the robot, with his new code, registered the exact number of lights beautifully every time.

The Pinbot Corridor

The pinbot corridor basically was a task whose behavior depended on two binary factors: whether the bumper was depressed and whether the light was on. After determining a satisfactory (single) threshold for our front mounted photocell (this was approximately halfway between our ambient light reading and our full-on incandescent light reading), the front photocell and bumper switch were essentially binary sensors. Because of the simplicity of the sensor data (only 4, or actually 3 combinations; the light doesn’t need to be considered on when the bumper isn’t pressed), the successfulness of completing the pinbot corridor didn’t depend so much on sensor to actuation behavior as it did on proper programmed motion and catching the line. We decided that to get back on the line after we had completed a pinbot bumper, it would be reliable if we were squared up with the bumper before we started moving and then moved back and turned a set distance. To square up to the bumper, we simply drove forward for a certain amount of time (about 2 seconds) after we detected that the bumper was depressed. Then after the task was done, we backed up for about 1 second and turned left for about 1.5 seconds, and the robot found the line every time. These times were determined empirically and had no dependence on sensors.

FORTH CODE

Files used:

This milestone saw a big overhaul of our code.  Basically, to be able to dedicate more time to line following, we decided to only look for the specific task that we were expecting next.  This was possible because the layout of the pinbot board is predetermined.  Our main loop looks like the following (written in pseudo code):

loop forever{
   while sensors straddle line{
      drive straight
      checktask
   }
   while sensor on line{
      correct
      checktask
   }
}

checktask:
   if taskcounter=1 then do task1
   else if taskcounter=2 then do task2
   else if taskcounter=3 then do task3
   etc...

After each task has completed, it increments the taskcounter so the next time checktask is called, it performs the next task.  The last task resets the taskcounter to 1, and so the tasks are performed in a loop like they appear on the track.  Presently, the order the tasks are performed is as follows, although this can be expanded or otherwise changed quite easily to accommodate a changing pinbot board.

1) wedge of death
2) light channel
3) barcode
4) flashlight corridor
5) pinbot corridor

DEMONSTRATION RESULTS

We completed the first demonstration with little trouble.  Unfortunately our board reset halfway through for unexplained reasons, but we were not penalized for this and were free to try again.  The second time we completed 2 laps with the 2 tasks with no problems.  The second demonstration, the time trial, went relatively well also.  We managed to tweak our line following to allow us to drive at full duty cycles with a large battery without loosing the line (except occasionally on the wedge of death).  With this speed we managed to complete a lap while accomplishing the flashlight corridor and pinbot corridor in 35.5 seconds.  This earned us 3rd place in the time trials, but until we get different servos, attach bigger wheels, or find some magic way to make our line following 4 seconds faster per lap, we will have to be content with that.  We cannot increase the power to the servos any more.  The final demonstration, when we had to perform at a certain time, did not go as well as we hoped.  Volt 45 approached the top of the wedge of death at an angle and, due to the fact that at the peak the line following sensors are father away from the line than when on flat ground, the robot lost the line and drove off.  This cost us 100 points, but that was not the end of the disappointment.  Because the robot was looking for the flashlight corridor, our software was polling for the synch bit to recognize the end of it.  As our robot drove off the wedge, the thin piece of white cardboard on the edge triggered the reading of a synch bit and the robot therefore thought it had already passed through the light corridor.  As a consequence, it skipped reading the lights when it actually was in the corridor and cost us another 100 points.

DISCUSSION/CONCLUSION

This milestone was one of the most enjoyable so far.  We were not confronted with too many problems that were not immediately solvable.  As a consequence, we only spent about 5 man hours working on hardware, about 18 man hours working on software (most of which was tweaking constants), and about 3 hours on documentation.  Most of our problems were physical ones which could be easily diagnosed.  For example, if two lights were on side by side in the flashlight corridor, at first our robot could not tell they were two separate lights.  To determine why, we hooked a voltmeter up to the right photocell and read the voltage in-between the lights.  There was hardly any voltage difference between being directly in front of the lights and in between the lights.  Once we realised this, we knew the photocell must be seeing light at too great an angle, so we build a blinder and attached it.  Then the photocell read values fine.  The following is a list of problem/solution pairs we encountered and devised throughout this milestone:

Problem: Could not detect enough voltage change between lights in the
               flashlight corridor
Solution: Put blinders on side-mounted photocell(s)

Problem: Synchbit transistor would register a "light" reading (i.e. synchbit
               present) while going through the flashlight corridore
Solution: Put electrical tape over the top of the transistor to prevent light
              from shining through

Problem: Couldn't be certain what angle we would hit the pinbot bumpers at.
               This was important because we decided to use programmed
               motion to back and turn to find the track again.
Solution: Once the bumper hit, continue driving forward for a fixed amount
               of time to "square up".  This way we can be pretty sure our axle
               will be parallel to the bumper.

Problem: Bumper would stick every once in awhile.
Solution: Grease bumper pistons, adjust mount angle.

Problem: Too slow
Solution: Use a bigger battery, drive at full duty cycle, reduce stopping time
               to beep.

Problem: Occasionally (i.e. when it matters most), the robot looses the line
               at the top of the wedge and drives right off.
Solution: In progress...

In conclusion, we think we are in relatively good shape for the final competition.  Our robot is very reliable (except on the wedge, but we think by changing our line following thresholds when we hit the wedge, this can be fixed) and is adequately fast, although more speed would be welcome.  We think our success in the final competition will hinge on whether we tackle the new optional tasks or not.  Needless to say we are going to try them, and because of our success in this milestone, we will not have to spend time fixing previously done work.