Team 17: SpiderBuggy

Strategy

During the development of our robot, our strategy went through many phases. The two constant attruibutes to our bot through its evolution were its extendable/retractable arm and speed. In the beginning, our robot was designed to race along the sides of the board to the left side of the board up to the side of the plateau. From there, it would then pick up the professor that is in its path, and then extend its arm to scoop the two professor blocks off the plateau and into our holding bin. Fron then, our bot races to the opponent's jail and delivers the 3 professors for -27 points against the other team. We decided that capturing the professors and delivering to the other team's jail would be the easiest way to score an insurrmountable number of points to secure a victory for our bot. However, during hardware construction, we realized the daunting task of creating a 3 foot retractable/extendable arm. The problem lied in the LEGOES themselves. LEGOES were not designed to support the weight of a fully extended arm, and this would then lead to a sugnificant bend in the arm of the robot. This caused a big problem in getting the arm over the plateau and the blocks as well as the problem of even having a motor be able to drive such a load. We decided to scrap this idea due to the many problems such an arm brought up, and also due to the fact that it seemed that this plan is slow in our robot getting the professors because many teams would go straight for the plateau. We decided to adapt our bot to this faster strategy of going for the middle professors. To do this, we decided to switch to a frontal arm. This would then allow our bot to race for the middle, extend the front arm, scoop the two profs from the plateau into the holding bin, and then decide which side prof to get next. The bot would employ IR detection to figure out where the other robot is, and then go to the side where the other robot is not at and grab that professor. Then SpiderBuggy would race to the opponent's jail again and deliver the profs. We ended up deciding on this plan, and quickly began implementing it and adapting our previous work.

Hardware

The final chasis of the robot ended up measuring in at 12'X9'X7' (width X length X height) with a 1"6' arm. Halfway through the original construction on the bot, we realized that we were running out of LEGOS for our robot. We decided to redo a lot of the chasis in order to build a robot that was lighter in weight and sparser in LEGO use. As mentioned earlier, the arm was a big structural challenge. The arm was designed originally at 3" and ended at 1"6'. The arm was designed to be retractable/extendable by employing the use of the lazy tong idea. The arms were connected for further support with braced axles instead of grey pegs. This considerably increased the strength of the arm and reduced bending. Another problem of the arm was the scoop in the front of the arm. Orignially a servo was designed to be attached to the front of the arm to raise and lower the scoop so that the arm could go over the blocks and then come down and scoop the blocks. However, this idea was scraped due to the heaviness of the arm. Instead, a scoop was braced to one of the beams of the arm, and then this scoop created a scooping motion as the arm opened and closed. This is a result of the scoop being braced to one of the beams, and therefore shifting in location and arrangment as the arms bend in the retracting/extending motion. The bin was also a main structural design concern. A worm gear was employed to drive two seperate 24 teeth gear that were then attached to the seperate arms of the bin. This allowed for the opening and closing motion of the bin. However. then bin was unable to be driven by a mototr due to our shortage of motor ports having 9 other bidirectional motors already. The gear train of our robot was a low 15:1. Each wheel was powered by 4 Polarid motors and the two rear wheels run in differential drive. This allowed us to be able to easily pivot our robot for tight turns and easy orientation. We decided on using very few sensors only employing them for orientation. We decided to drive and steer our robot mainly through hardcoding. The hardware aspect of our robot proved to be the most time consuming area. Our robot went through many designs and ideas. Building the robot, its motors, and sensors proved to be a longer task then originally planned, and we had not allotted sufficient testing time.

Software

Our robot code was written in Java, and then uploaded to our bot. Coding went fairly well for our robot considering that our team had very little prior experience with Java. All of the code was written in a matter of days, while hardcoding and testing of the robot took a considerable longer amount of time. The main concerns we had with software programming were working with minicom and having the board burn out.

Results

Unfortunatly, SpiderBuggy was never able to test out its master plan in the final contest. We were not able to qualify due to software loading problems and also sensor problems. However, we certainily wish we could have had a shot to compete with the other robots. We strongly believe in our strategy and in our construction of SpiderBuggy. from what we did see during testing, the robot was very fast, due to the 8 driving motors, and made very accurate turns. The robot also suprising drove very straight after some tinkering despite being hardcoded. The orientation of the robot was also very fast.

Designers

If you are interested in learning more about 6.270, here is the link to the page. 6.270 Page


Last Modified: Jan 31, 2000