This page is about the robot I built for the class 2.007: Introduction to Mechanical design, one of MIT's most famous courses which culminates in a competition event staged in front of 400 people and occasionally a national audience.
Benefits:
 |
After the preliminary thought experiments, I did some number crunching to see if this design would work (actually, I did some as I came up with the design to make sure what I was thinking was going to work) To the left is the spreadsheet I used to do proof of concept for the design. Using this sheet I was chose which motor to use, an order of magnitude expectation of how much time there should be between ball firings. At this point, I imagined I would be able to allow balls to roll into the shooter one at a time. Real-world testing without such a mechanism in place showed this to be not a particularly big problem, as the cylinders in general had enough stored energy to be able to shoot several balls in quick succession. |
| To the right is a to-scale sketch of what I intended my robot to look like. In fact, I used over seventy pages in my notebook for calculations, idea notes, scale drawings, and machining plans for this robot. Click here and here for some decently large pictures (~150k) of other ideas I considered before settling on the ball shooter idea. |  |
I learned pretty quickly that it's a
big help to draw as much as
you can up before coming to lab. Otherwise, you end up sitting in lab,
confused by trying to think of too many design parameters at once. On
the other side of the coin, the building process is a continual
process of design, build, and re-design, so you do need to come in
and play with the motors and the materials to get a feel for them. You
certainly can't design your whole robot and then just build it. If you
are, chances are your robot is too simple. Usually it takes a little
experimentation to get a tricky mechanism to work.
The priority for
construction I used was to start with the most fail-prone, doubtful
mechanism first. If I found there was no chance of it working after I
built a prototype, I would have committed as little time as possible
to it. To the right is a picture of the test ball shooter I built. Via
spreadsheet calculations, I was able to conclude that the two polaroid
motors were the way to go. Its design allowed for varying the distance
between the two cylinders, which proved to be an invaluable means to
with reasonable precision fire the balls the distance I wanted - to
the opponent's shelf. The axles are welding rod, and the bearings are
made of delrin lubricated with teflon. Happily, this mechanism worked
like a charm. I added the teflon lubrication to the bearings after I
burned out one of the motors. This was one of the big risks in this
design: I was sending 13.8 volts through motors that were designed for
6 volts, and they could burn out at any time. In preparation for the
contest, I did wire up two backup motors in case of another
burnout. But adding the teflon proved to be sufficient to avert burning
out these motors.
Mostly, I regretted losing the high-tech, intricate appearance these
tongs would have given my robot. As a result my robot appeared much
less well made than it could have. Essentially, I felt like this
design cheated me out of the opportunity to really show off my
machining skills. But such is the way of engineering. Besides, I knew
that even though I was losing something by not having these tongs, I
was in fact doing better engineering by not holding steadfast to a
counterproductive idea. A lesser engineer would have stayed with the
faulty mechanism for fear of making something even worse or running
out of time. As this contest has demonstrated to me in retrospect many
times over, nothing ventured, nothing gained. The decision paid off.
The next stage
was to
fulfill the design parameter of funneling the nine balls into the
shooter. After finishing the most critical and doubtful mechanism, I
started work on the ball acquiring mechanism. After about a week
working on the mechanism to the left, which was supposed to pick up
balls using a tong-like movement, I realized the importance of
cardboard mockups. With this mechanism, the balls went all over the
place. Only after much consternation did I abandon this mechanism. I
had painstakenly milled out holes in the lexan and aluminum to reduce
weight in the frame, did a complex riveting operation to save aluminum
on the tongs, and had even come up with an ingenious geometrical
mechanism to insure the two tongs kept the same angle with respect to
each other as they pivoted.
As I contemplated, it eventually became clear to me that I would have no choice but to take inspiration from past contests and build a "one-way valve." I had earlier mistakenly discounted the idea, thinking that a one way valve could only be effective for lifting very lightweight objects, such as ping-pong balls. I find this sort of thinking -- just coming to a conclusion without really thinking something through -- is an obstacle for any engineer who is trying to come up with an innovative solution to a difficult problem. For this reason, I prefer to work in small teams. In general the multiplicity of heads will do an excellent job of eliminating such narrow headed thinking.
To explain the mechanism here, the
rubber bands "press" through
the rack of nine balls and then restrict the balls from falling back
through. Hence it is a simple and elegant mechanism for getting a
group of balls. This mechanism was far superior because it was
mechanically far simpler, faster at getting the balls, and less prone
to failure. That it didn't look as cool continued to bother me, but
what recourse did I have? This was real engineering, and
what great bridges, yea, even Missions
to Mars, are made
from.
Here, the
prototype
ball collector is attached to a yet-to-be completed chassis. Once the
balls are in the collector, the arm pivots upward and funnels the
balls into the channel that leads to the twin firing cylinders. To
handle the problem of balls getting clogged in the funnel, I could
simply jostle the arm back and forth and they would fall through. I
was worried that this would be a problem, but that method turned out
to work just fine. Besides, the firing motors needed time to
re-spin-up between groups of balls.
Finishing the
robot
was essentially an excercise of throwing together two wheels (about an
hour of work when you're working in the beautiful, high-tech Papalardo
machine shop like we were), making a last-minute makeshift front two
wheels, and deciding in the end to scrap my pneumatic "ball pusher." I
already had an arm to push balls off the ridge, why did I need a
specialized pusher. This neglecting of the idea of using my arm as a
ball pusher was yet another example of the one-man tunnel-vision
syndrome. To the left are a side shot of the robot with its arm in the
collapsed state (to fit within the space constraints) and an isometric
view with the arm open.
Make no mistake about it, though. When the robot was visually finished, I was far from ready for the contest. One of my big advantages was that my robot was done a week early. Seppo Helava, great guy that he is, sacrificed his time to come in and practice driving my contraption on several occasions. This made a huge difference. Lots of practice was his idea. It was a good one. The first time we tried to drive it the robot was all over the place. There were funny noises coming from the ball shooters (teflon fixed that), and even one of the motors burned out, as I mentioned above.
At one point I came to the realization that I had set up my robot controls wrong for me: I had given my left hand the brainless job of running the ball shooter, and my right hand the delicate job of manuevering the arm. And that was just plain dumb: What had I been practicing for while I was playing Nintendo all that time? This contest, of course. And everybody knows it's your right hand gets the boring job of pushing buttons, and your left hand is the one that knows how to delicately manuever things. This was especially the case with Mario 64's proportional movement. Thanks to Keith Breinlinger, the head T.A. of the contest, we got proportional movement on two channels, which was exactly what I needed for the arm. So I improved the human interface to my robot as well.
While Seppo was at classes I made redundant parts and went through and made my robot ship-shape. Come the day of the contest, I was completely prepared, and my robot had been performing well enough that I wasn't worried about it failing. This, I now know, is a good feeling to have when entering a contest.
The Short Story:
The Long Story:
Out of ten: Five parts design and workmanship, three parts luck, and two parts driving skill. I thank tremendously Seppo "sQuink" Helava for some kick-ass driving, brain presence, mental support, and awesome strategy ideas during the contest. He's just off to the right of the picture above. You can see his right arm.
My strategy for handling potential nervousness was to concentrate on the fun I was going to have. I broke it down to: each contest is just a couple of robots, and I'm just curious what's going to happen, see if my robot was in fact a good design. It seemed to work pretty well. In general, we had no mental mess-ups, the robot worked perfectly every time (what bliss!), and we worked well as a team.
Some of the highlights:
Well heck, thanks for reading this page. I hope you learned something from it, and I hope you enjoyed it. I had a blast.
