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
- Winston Chang - Course VI-2
- Ray Cheng - Course VI-2
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