Chaos Theory

Design:

Our robot’s design went through many stages of development. At first we had planned on carrying the balls on top of our Robot. We also planned on picking the balls up one by one, but finally we decided that a simpler design would be more effective. We noticed how easy it is to mess up with a complicated strategy that depends on variables such as perfect traction and not hitting anything. So our design took a step toward simplicity. We stripped our robot down to the bear basics: Two driving wheels controlled by independent motors and front pivot wheel mounted on a servo. For eyes and ears we put three touch sensors on the front and two on the back to detect walls. Our robot also uses two photo sensors on its underside to detect starting orientation. We chose this simple design for it’s reliability so our robot would last the whole 60 second round without getting stuck or malfunctioning. As an added bonus we put a spinning disco ring (analogous to a disco ball) complete with colored LEDs reflecting off of it.

Strategy:

There is some innate beauty revolving around a chaotic system.
Our final robot was designed to create such a system.  Our strategy was based on two parts:

1. 1. Score 1 ball

    With “good” (about 90% of the time) accuracy we were able to consistently knock
in the ball closest to the wall.  The way this was achieved was to first orient our robot
towards the scoring area, then drive forward as straight as possible to the wall.
    We detected our orientation by detecting the color of the floor in two locations.  The
sensors were placed at the rear of the robot placed as closely possible as we could
manage (0.5 inch).  We rotated about the center of the starting pattern until we “saw”
black on our right and white on our left.  Once we “saw” that, we were oriented in
the right direction.
    The robot was calibrated to drive straight.  As soon as the orientation was set, it
drove forward.  Our error came due to the fact that we were only basing our orientation
on two photoreceptors on the back of our robot.  Our error came from the angle
resolution of our robot.  What we mean by this is the amount of angle that fit within
our reading of the correct orientation.  Fortunately, we found this to be insignificant as
we ran our robot, so we basically ignored it.

2. 2. Stagger around the board randomly.

    We had three touch sensors on the front and two in the back.  No more sensors were
necessary for what we wanted to do.
    When detecting whether we hit something or not, we checked the front sensors (we
assumed that we were always traveling forward in some direction).

If a front sensor went off, we drove for a little more, then detected for a collision
again.  If at the second reading we were not touching anything, we assumed it
was a ball and continued.  If at the second reading we were still touching
something we went away from what we were touching by:

If our left sensor went off, we backed up then spun right randomly.
If our right sensor went off, we backed up then spun left randomly.
If our middle sensor went off, we backed up, then spun right or left randomly.

If a front sensor did not go off and it had been longer than 4 seconds since the last
bump, we spun randomly.

    Our randomness was based on time.  The time in milliseconds was taken and a modulus
of that was taken to give a certain resolution, which we took as 10 for most of the code.
Based on that number, we decided how much to spin by taking a constant plus a multiple
of our modulus.
    We had calibrated this angle to be anywhere from 30 degrees to 180 degrees, which
meant that the robot just bumped around all over the table.
Word of warning: Achieving randomness is not trivial.  Modulus is not a built in
function in IC in the type long nor is there a simple random function.  Time was used in
our code because the resolution of the mseconds function was in milliseconds, which, if
looking at the last digit only, is about as random as you can get.  To get modulus working,
we pretty much brute forced it (a while loop subtracting until the number dropped below 10).

And that’s pretty much it to our robot.  Thanks for visiting our page.

-Carlos Vila, Dan Lee, and Derik Thomann