CS 491X: Robotics
Team 4:
Brent Devaney
Adam Olenderski
Sebastian Smith
Final Report
Introduction:
We built this robot for the CS 491X Introduction to Robotics Final Competition. Our
goal was to take golf balls from a playing field and deposit them onto a black circle in the middle
of the board. There were two robots wandering on the playing field at a time and had to compete
over twelve balls. This document covers our software as well as our hardware design for the
robot.
Software:
Overview:
Our robot essentially alternated through three stages, or states. We decided to make the
robot begin the race by pointing itself towards the starting line balls. It would then wander
around for 25 seconds. Finally, it would attempt to deposit the balls. Since the robot was able to
hold several balls at once, we thought that picking up as many balls as possible and making
active drop-offs periodically would be a better idea than wandering around randomly the entire
race and attempting to eject the balls every time the robot detected the well, which took up
valuable time.
Orientation to Balls:
First, the robot would find out in which direction it was facing at the beginning of the
match (when it “woke up”). It would drive forward a bit, back up, turn, and drive forward again.
By the number of times the bump sensors were triggered, the robot could determine in which
direction it was facing and where to turn to orient itself towards the six golf balls on its side of
the arena. This series of actions was stored in a single module called orientToBalls(). When the
robot hit the wall again, it would switch to the wandering state.
Wandering:
While, wandering, the robot had three processes running in parallel. The first process is
called evaluateSensors(), and would evaluate the status of the sensors each time through an
infinite while loop. It would then store the values of the optosensors and the bump sensors in a
global array of sensor values.
The second process (the move() process) would then use this sensor value array to move
the robot around the board. To prevent the robot from moving backward (which would
prematurely eject the balls), the robot would only move right when the left bump sensor was
activated and would only turn left when the right bump sensor was activated. A few more lines
of code were added to help get out of corners and the like, and the move() function was
complete.
After the 25 second timer, the robot would switch states to the Deposit Balls state and
begin looking for the black “well.”
Deposit Balls:
The third and final state was the depositBalls() function, which activated itself after every
25 seconds of aimless wandering. The depositBalls() function would take control of the motors
away from the move() function (by killing the move() process and starting it up later, essentially
inhibiting the output of that behavior). The depositBalls() function was similar to the move
function in that it checked the sensors repeatedly to determine when to turn and escape corners,
but it had one important difference: one wheel was always getting more power than another,
causing the robot to go around in a spiral around the board. The reasoning behind this is that
after catching as many balls as it could in the first few seconds of the game, it would take a few
seconds to maybe pick up a few more, and would then actively look for the well in which to drop
off the balls. After finding the well and ejecting the balls, the depositBalls() function would
reinstate the move() process and wait another 25 seconds.
Advantages:
Our software was very well designed. By making the processes act in parallel, the robot
was much more responsive to the world. Also, by having the multiple states, the robot was able
to have a controller similar to a behavior-based system. The orientation function worked well as
did the depositing function.
Disadvantages:
There was no true disadvantages to our software design. During the tournament,
however, we did run into a few glitches. If the optosensors picked up a false positive and the
robot thought it was on the well when it really wasn’t, the robot would eject its balls and would
not be able to make another dropoff for another 25 seconds at least. False positives only
occurred, however, when our robot collided with the other robot and the front end of our robot
was lifted, causing the optosensors to lose reflectance and think it saw black.
With that small exception, the software performed very well in cooperation with the
physical design of the robot, leading to what was arguably the best performance of the entire
tournament.
Hardware:
Body:
We began designing the robot around a pit to carry the balls. We started with a simple U
shape and built upon that. We made the robot strong enough to collide with other robots without
any damage. We made special use of brace beams. These kept the construction sturdy. We also
took care with the wire placement to avoid having them get caught on other robots.
We ran into problems with the camber getting too high when the robot was running.
Camber is the angle of the wheels when you are looking at it from the front or the back. To
solve this, we put the wheel axles through a double-lego brick. This still did not accomplish
what we wanted, so we added another lego piece on the outside of the wheels gear for more
stability. This worked extremely well. The axle had plenty of support and would not bend. This
allowed us to have a consistent driving pattern from the wheels. We also chose to use two of the
large wheels on each side. This gave more traction with the playing field. The advantages of
this were two-fold. First, we could rely on the robot acting similarly every time we ran it.
Second, if another robot were to collide with us, we will have a better chance of not being moved
by them.
Ball Mechanism:
We wanted to be able to carry 6 balls reliably. Turns would be a problem: the balls were
sliding out of the robot whenever it executed a turn or backed up. We decided to put some
mechanism in the front to solve this problem. It ended up being a long axle with wheels on it
that was driven by the same motors as the wheels. We had a gear system, with a pulley finally
driving the front axle. Whenever the robot was going forward, it would spin the front wheels to
“suck” balls into the interior. Whenever the robot turned, the pulleys would slip resulting in no
movement of the front tires and no balls escaping. To eject the balls, the robot had to go in full
reverse. We actually made the robot rock back and forth 5 times to eject all of the balls
contained within.
Bump Sensors:
The bump sensors were mounted on either side of the robot’s ball trap. We put a bumper
with a lego piece wrapped in front of it. This was put there to enable the robot to follow walls
very easily and to scoop balls into the middle of the robot to be sucked in easier. We had to try a
few different designs on the bump sensors to find a reliable one. Ours is extremely simple and
braced with a rubber band. The rubber band also serves as the device that pushes the bumper
from setting the bump sensor off the entire time.
Light Sensors:
We ended up positioning the light sensors right behind the bumpers on the front of the
robot. We wanted the front sensors to be the reliable sensors to detect the well easily. We
initially put the cheap LEGO sensors on the back of the robot to conduct the line following, but
we discovered that those pieces were truly cheap. They could not even detect the black line on
the white playing field. So we removed those and had to rely solely on the front sensors.
Advantages:
The ball trapping mechanism worked extremely well. We kept the balls inside the body
very well. The wheel setup also was a good design feature.
Disadvantages:
The rubber bands that the front tire pulleys were on started to stretch by the end of the
competition. This was probably from the forcing the pulleys to slip when the tires turned
opposite directions. This cause our robot to not collect the balls as well during the later matches.
Conclusion:
We were very satisfied with our robot’s performance. It finished third overall, but
collected the most balls and had the most wins during the competition. We learned a great deal
from this competition including: robot mechanical design, parallel execution of robot commands,
and solving a problem presented to us in the best manner.