20/20 Vision

Paul Chang, James Oey, Jeremy Wong

6.270 main web page

Strategy

Our robot's original strategy was to turn towards our side of the playing field, grab the ball nearest to us, and then go to the opposing side. This was a variation of the typical strategy that most robots of our type employed, as it effectively scores a negative point until our robot could return to our side before the 60 seconds was up. This is to our advantage because if we pick up our own balls, then we steal the ball that our opponent would pick up soon. We assumed that due to our robot's capability to "scan" for balls without line following, we would not need to rely on the original position of the balls as much as other robots. However, upon viewing other robots and observing our robot's trial runs against other robots, a good number of flaws in this strategy were exposed. Firstly, in constructing a relatively complex lifting and ball finding mechanism, we didn't spend nearly as much time on things such as driving straight as most other groups =PIn addition, our geartrain was horrible, and we ended up rebuilding it two days before qualifying just so our robot could move on the uphill portion of the playing field! (Let that be a lesson to all of you poor saps who haven't taken 6.270 yet... DEAL WITH THE SIMPLE STUFF FIRST! =) In the end, we adopted the oft-used strategy of first turning towards the opponent's side, picking up the nearest ball there, then going for the second ball on that side. If our distance sensors did not detect a second ball there, our robot continued to move around the opponent's side and scanning until a set time, upon which it returned to our side and sat there.

Design and Implementation

Hardware

Our idea was that if our robot held our balls, then we would certainly own the balls and wouldn't have to fight of over that ball again. This led to certain restrictions in our lego design. First, we used almost all of our legos because we needed to build a strong robot with a center hole for the balls to be stored in. To the side of this rectangular hole, we needed our two gear trains to have a differential drive robot. The front of our robot would contain the arm that would be capable to lifting the ball. Initially, we chose a 45:1 gear ratio for each wheel, and about a 3200:1 gear ratio for the arm.

We used differential drive, meaning that we had a gear box for each of the two main wheels, and a single middle steering wheel powered by a servo. To implement the different drives, each wheel had to turn at a certain direction. For example, if one wanted to drive straight, both wheels would have to drive forward. However, if one wanted to drive backwards, then both wheels have to drive backwards. In the special cases of turning, the wheels would have to rotate in opposite directions. In the case of left, the left wheel would have to go backwards and the right wheel forward. For a right turn, the right wheel would have to go backwards and the left wheel would have to drive forward. This leave the question of what to do with the middle wheel. For driving forwards and backwards, the wheel remains straight. In the case of turning specified angles, the middle wheel would rotate 90 degrees to allow such turning. In some cases, the middle wheel would turn only slightly if the robot were to veer.

Our robot consists of a number of sensors. For each wheel, we have a shaft encoder to measure distance travelled by each wheel. This allows for accurate turning as well. We use a pair of bump switches in front to help the robot travel among the board. A center switch on the arm detects whether a ball is in position to be lifted. The last, and most complicated sensor is the pair of distance sensors mounted on the arm. Using two distance sensors allowed us to figure out where balls were wherever the robot and the ball was on the board. This is explained in the software portion of the design description.

During the last weekend before the competition, our robot underwent a complete redesign. The 3200:1 gear ratio changed to a pair of servos, turning the lifting-a-ball time from 6.3 seconds to about 0.5 seconds. This turned out to be a big advantage, saving us lots of time.

Later, a complete redesign of the main drive gear trains allowed the drive to run much more smoothly. The cut of more than half of the gears in the train reduced enough friction to allow quick movements and more turns. In the last 24 hours before impounding, the software for the drives were rewritten and retested.

Our robot is almost a foot wide, 8 inches long and 7 inches long.

Software

Code for 20/20 Vision

Our robot control software was designed to be flexible and robust. To a good approximation, this was the case once a round began. Our primary concern was to give the robot the ability to find its way back to its own side consistently. Our robot can travel anywhere on the opponent's side to get a ball it has scanned for, so the return routine must be general. In addition, we added stall detection and timeout recovery to assist with collisions, ramming code against enemy arms, and the ability to return on the side of the table not occupied by the opposing robot.

We unfortunately spent quite a bit of time writing software to try to bypass some of the hardware difficulties the robot was having. In particular, we tried to add a regression function to make turns more precise, and more complicated ball recognition routines to account for a downwards angle for our distance sensors. Neither fix was good enough to improve performance on suboptimal hardware.

A note to future contestants: The Handy Board is limited in processing capability and memory. Storing any substantial amount of old data will overflow the stack (fifty integers in an array is too much). Furthermore, the effectiveness of shaft encoders is greatly limited by the time it takes the feedback loop to execute. We could only get a maximum of about 30 readings per ninety degree turn. Running parallel processes (such as ball detection) during movement lowers precision even more.

How we did

A couple of days before the qualifying round, we were actually feeling pretty good about ourselves, our robot, and our relative position compared to other groups. Big mistake No. 1!=P It wasn't that we became complacent, but Murphy's Law was really shining down on us, to be sure! After realizing that despite three motors per wheel our robot couldn't even move up the incline of the board, we decided to rebuild the geartrain. This was no small task, since doing this meant that all our calibrations and shaft encoder routines would need to be recalculated, but there seemed to be no other way if our robot was to move around with any speed =P.That night, James rebuilt our drive mechanism with about a third of the gears as the previous version! While this was an awesome thing (go James!), it was another 6-7 hours before our robot could drive straight and turn somewhat accurately again. We essentially worked up until qualifying, where we didn't qualify due to some untested start code that we put in just before the round. We vowed to do better for the second round, or at least start! Over the next two days, we made a significant amount of improvement in our robot and theoretically ironed out most of the kinks we noticed earlier.The morning before impounding, we had a pretty good feeling that our robot would at least be competitive after pitting it against other robots that were in lab at the same time we were. Alas, 20/20 Vision was just not meant to compete. It was too trigger happy in the second round, and false-started twice, leading to a disqualification.

Things that went wrong