Monday, March 3, 2014

SciBorgs Day Two: The Puzzle of Feedback and Control Continues...

The journey to understanding feedback and control continues...

For today's challenge, my partner Michelle and I had to make our SciBorg (Snow White) drive ten feet in a straight line. It sounded easy enough.

But it was WAY more difficult than we expected.

We started with a simple 'move forward' command.

Up a Little and to the Right...

Our particular bug had a tendency to bear right. If we were ever hoping to have a straight bug, then we would have to find a way to fix this. We decided to find out why this unexpected turning was happening. We needed to see what the difference was between motor a and motor b.

We achieved this by measuring the discrepancy between counts (at the moment an unspecific unit of measure). Over a distance of ten feet, countb measured 3056, while counta measured 2978.

The discrepancy between the two motors was approximately 78 counts when they were simply commanded to go forward at equal power levels.

After much guessing and checking, we finally managed to get the bug to go a full ten feet. We then measured the value of a count. The bug moved 3056 counts in ten feet. That's 305.6 counts per foot. Which is 25.47 counts per inch.

Although these measurements were accurate for this particular trial, we found that the discrepancy between the motors and the distance in counts covered in ten feet varied depending on where the bug ran, how fast it ran and how much friction there was between the wheels and ground. Certain areas of the floor were bumpier than others, and even though the lab floor provided the lowest friction possible for our bug, it still had an effect. Any skidding or slipping that occurred was reflected when we measured the discrepancy multiple times. If the discrepancy was smaller, slipping occurred, because more rotations happened. If the discrepancy was larger, skidding occurred because fewer rotations were counted.

We then wrote a program to try to account for these variables.

Go Ten Feet and Account for Count a and b Discrepancy

Entitled GoStraight, the program gave specific commands depending on where the car was and how large the discrepancy was between counta and countb. When the bug was one third of the way along the track, the power to motor b would drop to 99%. 

Mistakenly, however, we dropped the power on the wrong motor. After checking Snow White, we discovered that it was motor b, not motor a, that was running slower. We tried switching out the count to reflect this correction, but then the bug began turning left.

We needed a more complicated program that effectively accounted for the differences between motor a and motor b. 
Go Ten Feet and Account for Count a and b Discrepancy Version 2

We dropped the power to both motors to 90%, set the counts both at 0 initially, and had motor a drop to 89% one third of the way along the route. 

Better...Sort Of

Snow White definitely went straighter. However, it still had a tendency to veer slightly rightwards the farther away from the starting point it moved. 

Moving into the feedback portion of this challenge, we tried turning respective motors off whenever the counts were uneven to see if the car would continually correct itself along its path. 





The bug did continually correct itself, but along a rightward trajectory. Even turning only motor a off for a small interval of time could not correct this behavior. We returned to our original program, fiddled with the power allowed to each motor, but always our bug had a slight rightwards tendency when it traveled over long distances. We decided to see if sensors and more feedback could potentially fix this problem.

Because ten feet was placing us in the way of other working groups, we lowered our track distance to five feet and tried to see how close we could get the car to adhere to this distance. 

We started with the touch switch on the from of the bug. When the button could either read 999 (unpressed) or 0 (pressed), so it was a simple measuring device. Basically, it asked a yes or no question. 

Go Ten Feet and Stop When Touch is Pressed

Entitled gtfst (go ten feet stop touch), our program ran the previous course, but after a while, a sensor was activated, that when the button was pressed, would stop all power to the motors. 



The sensor worked. When the car came into contact with the bin, however, it moved slightly over the line. Because the car had momentum when it encountered the box, it could not immediately stop, so the box was moved a little. However, if the box had been a solid wall, the car may have bounced off it, or even sustained some damages as as result of the collision. Additionally, the button had to encounter the object dead on. Any turns or odd angles of contact might now have provided the proper force to activate it.

We moved on to the ultrasonic sensor. Entitled, gtfu, this program had the robot stop initially one hundred units from the box. After we were sure it worked properly, we lowered the distance to 1 unit, which should have placed the bug right on the line before the box. 

Go Ten Feet Stop with Ultrasonic



Even with the unexpected left arch, the bug was still a few inches away from the line. Because 1 was the lowest possible setting for the ultrasonic sensor, we could not rely on it to place our bug exactly on the line if the box was close to it. It could not effectively approach the wall. However, the bug did stop effectively, and without the requirement of contact with the wall to stop it, there was no risk of Snow White breaking. The lower the power was on the motors, the more precise the stop. Even though the bug did not have to hit the wall, it still had some momentum when the sensor tells it to stop and tended to jerk and then stop rather than stop immediately. In an annoying twist, we ended up having to tie our wires down more securely because whenever they fell in front of the ultrasonic sensor, the bug ground to a halt. Despite its setbacks, this sensor had potential to be useful for our program.

Finally, we tested the brightness sensor. We had to measure the difference between a light and dark color so that the brightness sensor could know what to 'look' for. We found that a dark color was in the 500s range while lighter colors, like white, were in the 300s. We set the middle ground as 400. If the sensor recognized anything above that, it let the motors run, Anything below 400 caused the motors to turn off.

A Nice Stop


Go Forward and Stop with Brightness Sensor

Go Forward and Stop with Brightness Sensor

The brightness sensor worked extremely well. So long as the sensor eventually ran over the line, it did not matter if the bug's path was perfectly straight. Additionally, the large discrepancy between the light and dark colors of the floor and line made it easy for the sensor to distinguish the two. However, if the power on the motors was set anywhere above 85, the bug ran the risk of overshooting the line. Even though the sensor would see it, and the bug would stop momentarily, the bug would be moving so fast the sensor would end up on the opposite side of the line, see the floor, and tell the bug to keep going. So long as the power was low, however, the brightness sensor worked well. It stopped right on the five foot line, whereas the touch sensor landed the car one inch over and the ultrasonic had it stop several inches too short. The brightness sensor worked the best by far. 

To get the bug to reach an exact distance of ten feet with minimal turning, we used both a touch and brightness sensor. Whenever we turned the bug on, the act of pressing the small white button put extra force on the right side wheel. In order to reduce friction and help with the turning problem, we instead activated our code by pushing the touch sensor. The bug moved forward and stopped when it found the line. We also incorporated our original code that changed the power settings to the motors after a set distance. We called this procedure sbb (straight bang bang).

Go Ten Feet Exactly and Stop


We then tested this procedure on a variety of different surfaces. It ran relatively straight on the lab floor, although by the time it reached ten feet it was still bearing a little bit to the left. On the carpet, it performed just as well, though the white line needed to be thicker to prevent the bug from overshooting.



It was the ramp that presented the most difficulties.

When it was traveling down the ramp, the bug had very little grip on the smooth wood and effectively slid the entire way down. It it could not stop itself when it saw the line (we changed the sensor settings so that when it saw a dark color the motors would turn off). 

Where are the brakes on this thing?!?

We were afraid at the speed it was going that if it hit the trashcan at the bottom it might break. It did make it all the way down the ramp without falling off, though.

Going up the ramp was even harder than going down it.

The rightward tendency was more pronounced going up the ramp than it was on any other surface. On every attempt the bug eventually tumbled over the right side of the ramp (we caught it each time, fortunately).

We Tried Again...

and Again...

and Again...

and Again...

...

...

...

...you get the picture

On one attempt, we managed to get our bug to traverse more than half the distance, but ultimately our procedure that worked on the ground could not work on the inclined plane. We tried using the brightness sensor to help the bug know when it was crossing over the edge, but the gap did not register correctly or consistently enough to work sufficiently. It is possible that the friction between the wheel was different depending on the side. Even with dramatic right turns and the power on motor a reduced to 75%, the bug still toppled over the edge. 

Finally, we attempted to make a line follower. Surprisingly, despite the procedure's more complicated program, it was actually easier to make. We used a simple if-then-else statement to activate the motors. When the brightness sensor registered a light color, one motor turned on and the other turned off. When it registered a dark color, the opposite happened. In addition, we also reduced the power on the motors to 80% so that the bug would not overshoot the line.

Bang Bang Line Follower




Needless to say, it worked extremely well. 

If we had more time, I would have liked to have fiddled more with the uphill procedure, as several other groups demonstrated that a successful procedure is possible. Aside from this, I was happy with our results, even if our little Snow White had a tendency to pull to the right. If we just lay tape down all over the floor, she can travel perfectly straight. 



1 comment:

  1. We also had trouble making our SciBorg go straight up the ramp and it was very frustrating!

    ReplyDelete