People
Strategy
This year's
contest board offered the contestants with a lot of different possibilities to score points. With the 60
second time limit we were given, each team had to figure out how they could most efficiently collect the
greatest number of points, and that meant that we had to pick one strategy and perfect it. After analyzing
the possibilites and calculating maximum scores for several different strategies we decided that the best
and most feasible strategy would be to make a rectangular loop, collecting and sorting through all the
blocks on our side. We saw that if we could bring all the hackers back into our jail and not possess them,
while leaving the students on our campus, we would have 24 points, which seemed as if it would be enough to
beat most other strategies.
In the end, we did not have enough time to get our entire
plan working, so we had to modify our strategy at the last minute. In this new strategy, we basically did
as much as our robot could at the time of impounding: our robot was reprogrammed to pick up each hacker on
our side and bring them back to jail, which would give us 8 points if done correctly. The main reason that we
were not able to use our main strategy was that we lacked the ability to line follow, which we had not had the
time to test and put into practice on the actual table. We had tested and calibrated shaft encoding pretty
well, and that allowed us to turn effectively and run a certain distance both backwards and forward, which
is all we needed to pick up the two hacker blocks.
Design
- Drive Train - We used a 3 wheeled design for our robot's drive train; the front wheel mounted on
a servo which allowed us to turn, and each of the two back wheels mounted off of one motor and a 45:1 gear
train. The basic principle behind this was that if the front wheel was aligned directly forward, then the
car would move perfectly straight if the back motors were run at the exact same rate. And if the servo was
turned to 90 degrees, then the car could turn about the center point of the back axle if the motors were
run exactly opposite one another. The 45:1 gear ration allowed us to run the car pretty fast if we wanted,
but we found that if we ran the motors at just 40-50%, we got enough speed for the size of the table we
were given.
- Collection Mechanism - This was the part of our design that most influenced how we built our
robot. It was the main part of our strategy, and we knew that our machine had to be able to collect and
sort the blocks well, or else we could not score the number of points that we needed. We came up with
many different ideas of how to sort and collect the blocks, and finally decided that we should go with
the simplest design. We used a mechanical sorting method to avoid any problems that could arise with
photosensors as we imagined that these would not be very precise or fast. Our solution was to mount a
horizontal axle that was parallel with our direction of motion, which would "skewer" the hacker blocks
we wanted and refuse the student blocks which we wanted to leave on campus. To get rid of the blocks
that we did not want, we used a servo driven gate mechanism, which pushed blocks away from the tip of
the axle if they were not skewered. We had two chutes that would funnel the blocks onto the skewer,
each the length of 4 blocks, which was the maximum we could encounter in any round of competition. The
chutes were positioned exactly 8 inches away from each other, as that was the separation of the blocks
on the table. At the entrance to each chute was a funneling mouth, that would accept blocks into the
chutes just in case we were not going exactly straight.
- The other part of our collection mechanism was the only part that we really ended up using. Since
we knew the position of the two hackers on our campus, and knew that they were located directly on a
line, as opposed to the other ten blocks, which were off the lines a bit, we knew that if we started
straight on a line, we could just put these right into the belly of our robot. The problem came in
that we had a wheel mounted centrally in the front of our vehicle, and the previously described
collection mechanism was located off center. So we overcame this by driving backwards over the
hacker blocks, and lowering a gate that would pull them along with us when we went forward.
- The uniqueness of our method of collection was that we exploited the rules of possession that
were given to us in the competition. We found that if we collected the blocks in this manner, we
could have all the blocks underneath our robot, but not possess any off them if we opened up all our
gates at the end of the round. And if we were not able to get back to jail for some reason, then we
could be sure to at least possess the hackers we had by closing all our gates when time ran out.
- Controller board and sensors - We chose to use the Handyboard for our robot, and definitely
felt we benefited from it. Its lightweight, compact design was easy to incorporate into our robot's
structure, and its use of C made it easier for us to implement our ideas.
- We mounted 6 line following sensors underneath our car, which we ended up not being able to
use.
- We used 4 well-shielded CDS cells mounted in 4 perpendicular directions to orient our car in
the beginning, and 1 equally well-shielded CDS cell underneath the center of our car to pick up light
from the start light at the beginning of the round.
- The main sensors we implemented were shaft encoders. We mounted 1 directly on each axle of our
back two wheels. We had planned to use those to count distance, but found that there was a better
method. This method was to just mount one shaft encoder further up on the drive train, so that it spun
much much faster, and could be a good deal more precise with its distance counting. We used this shaft
encoder to count the distance we went, as well as the turns we made.
- We mounted an IR beacon, but did not use it at all to track the other robot, which was its
sole purpose in the competition.
Results
We were not as succesful as we had wanted to be with the
original design we had built. This was mainly due to the fact that we did not leave ourselves enough
time to do testing of our robot's strategy. We
encountered the standard problems as everyone in testing our code for orientation and calibrating shaft
encoding. Due to these problems, and just that we had grand plans, and not enough time to bring those
plans to fruition, we ended up quickly paring down our strategy to that described above. In the first
round of competition, we had the most unfortunate thing happen to us. We were facing a robot that
obviously couldn't do anything, and our battery decided to run out right after we started. So we were
not able to score, and took a loss. In round 2, we were all charged up and ready to go, and we easily
got the 8 points we wanted. This allowed us to get to the evening competition. In round 3, we were
plagued by the hasty nature with which we wrote our code, and the orientation of our robot caused us
to select a direction so that after we dropped off the first hacker in jail, we did not make the 180
degree turn needed to get the other block, and thus proceeded to knock the hacker out jail, and thus
scored 0 points, and took our second loss to exit the competition.
We were disappointed that we were not able to proceed
further, as in the end, the robots that could get those 8 points effectively got as far as the final
round of competition. No one would have been able to beat King Louis in this way, but we definitely
could have gotten a lot further. We learned a lot about real world testing and building, the truth
in robot development and taking ideas and making them a reality. The class in itself was an amazing
experience for both of us, and we would love to be a part of it again.
Got any questions or comments? Send em to Neil or
Stefan. And wondering where the name and logo Average White Robot comes from? Check out
this page for a truly funky experience.