Project 1: Robot Design Paper
Group 7: Robert Moe, Celi Sun, Mark Woehrer, John Zumwalt
Due: Monday, February 17

When designing our robot our initial plan was to keep the robot as simple as possible.  We wanted to minimize any possibility for failure due to mechanical or structural problems.  The design that was agreed upon by the hardware team was a simple box cart with the handyboard sitting on top and the drive train and motors below it, we wanted to minimize the width of the robot as to have the maximum amount of space for the robot to have when entering the black squares.  The following paper will discuss the transition of our robot from the first prototype to the final design in which we successfully accomplished our goal of 3 runs.

The first design that the hardware team developed was a simple box shaped cart with the handyboard on the top.  The wheelbase however was wider that the top section of the cart.  This was due to the fact that we had not perfected our gear system and the wheel encoders were mounted next to the wheel which caused us to widen our wheel base by 2 1/2 Lego blocks wide. This design also caused some drag with our gearing system.

Our gearing system was fairly complex.  The first design for the prototype we had the 40 tooth gear on the motor and the 8 tooth gear on the axle.  Our though was that this would allow us to have maximum speed down the straight away so that we might be able to make the run in less than 2 1/2 minutes.  However we soon found out that such a high gear made it almost impossible for the Lego motors to get the robot going with the full load of the handyboard.  This design was scraped fast.  We later did the opposite and added the 8 tooth gear to the motor and the 40 tooth gear to the axle which allowed for high torque but lower speeds.

This design however was not working.  The wheel encoders where attached to the 40 tooth gear axle which did not allow the wheel encoder enough resolution per rotation to get a very good reading. With the current setup we only achieved 12 ticks in the encoder per 1 revolution.  On a full 6 foot run this was only 40 - 45 ticks per run which did not allow us to determine if one wheel was traveling faster than another. We had to come up with another plan.  

Our 2nd drive train design was much simpler and achieved our goal of 60ish ticks per revolution.  Our drive train consisted of at 8 tooth gear on the motor which then rotated a 40 tooth gear that ran the axle to the wheels.  Then on the other side of the 40 tooth gear was another 8 tooth gear that was attached to an axle that contained the wheel for the wheel encoder.  Another advantage to this gear design was that we were able to put the wheel encoders inside and underneath the handyboard which allowed us to shorten the rear drive train to the same with as the front and just as wide as the handyboard.  Another plus was that all the encoders and wires were hidden underneath the robot as to minimize the possibility of being damaged or moved if outside of the cart.  This design we kept all the way through the final robot design.

Another issue we had was for the placement of our IR sensors.  At first thought we believed we should have these sensors next to the wheels as close to the ground as possible.  This would allow us to line up the drive wheels as close as possible on the black tape if the sensors were right next to the contact point of the wheel to the ground.  This unfortunately widened our robot again because we had to design a platform for the IR sensors to sit on that went around the robot.  We tested this out for while and determined that it did not matter if the IR sensors were next to the wheel or in front of the robot as it would still line up the robot straight on the line.  So the hardware team went and designed another box container for the IR sensors and mounted them to the front of the robot.  This again brought our robot back to the desired with and allowed for less chance of error than having the sensors outside of the robot. This might sometimes give the robot a false sense of position where as if the sensors where in front of the robot it would give the robot an exact sense of position relative to the black tape.

Our final issue that we encountered with the robot was the ability for the robot to drive in a straight line. This phase of the robots design went through many changes. The first of the designs had the robot in a tri-cycle type of arrangement with the rear two wheels as the drive wheels, each with its own motor so that it can turn 90 degrees, and a dead front wheel.  This design did not prove to allow the robot to drive in a straight line. We then went to a second design of placing two dead front wheels and having the same rear wheel drive system as before. This proved to have better performance but did not turn accurately and still did not drive straight as was desired.  Our team then began to experiment with caster type systems as well as just a peg to drag instead of wheels to better improve turning. This turned out to be a disaster as the robot would not drive straight with a caster after turning because the caster was not in a straight position and the robot was not long enough to compensate for turned caster before it straighten out.  The peg would catch on the tiles or any piece of dirt and cause the robot to spin out of course and then the robot was doomed.  We decided to go back to the 4 wheel design but instead of pushing the robot with the motors we should change it to front wheel drive and pull the robot. This proved to be a much greater advantage.  We also matched the motors better and along with front wheel drive the robot was able to drive straight with at most an inch of drift, but on average was right on target from square to square unless the batteries were low and one motor dominated over the other.

With all of these problems accounted for and solved we were able to successfully traverse the course in our lab setting 25 consecutive times without touching the robot.  We could have let the robot continue to run but the batteries were running low and the robot was having a hard time going forward.  With these 25 consecutive runs along with our previous average of 16 runs without an error we decided that the robot design was adequate for the task and no further modifications were made to the design prior to running the demonstration.