ROBOT COMPETITIONS - MOBOT
MOBOT is a competition that looks very easy on first look, but turns out
to be much more difficult than participants ever expect. Anything specific
about MOBOT, such as rules, past rankings, map of the course, and any other information can be found
on their website, MOBOT. This page will be
dedicated to helping you win instead.
What is MOBOT? This competition is held every year during Carnival at
Carnegie Mellon University. A quick note, it is open for anyone to participate,
but placing and prize money are available to students and alumni only.
Want to see more?
View the official MOBOT competition videos,
some unofficial MOBOT competition videos, and the
most recent MOBOT 2008 competition videos.
Also, read MOBOT news articles in The Tartan,
and the 2008 races on c|net's news.com.
Quick rules rundown.
Design and build a fully autonomous robot (or train an
non-sapien like animal such as a dog, yes I am serious, read the rules) which can follow a
white line. Sound easy? They got kits out there that can do that, right?
WRONG. One word, the competition is OUTSIDE. No more perfect idealized world
of perfectly flat floors, high contrast lines, and controlled light settings. 50% of all competition
entries cannot even get past the first gate (excluding the start gate, which
by the way I have also seen an occasional MOBOT fail).
So to help you win MOBOT, first I am going to explain where so many robots
go wrong, and then I will explain how the winning robots solved these problems.
I want to stress that you should solve each of these problems in this order. Only
bother with the next problem after you have solved the previous. Trust me.
If you are curious of my credentials, I have built 6 MOBOTS, competed with
four (all named Pikachu), and placed each time.
The white line is contrasted on a grey concrete background.
This is the first problem all contestants 'solve.' It is rare to find one that
has not. But believe it or not, their algorithms and circuit are still often lacking and
on competition day 1/4th of entries fail from this problem. When designing
your line detection circuit/algorithm, test test test. Optimize for that perfect
resistor value, or that perfect camera algorithm. You need to maximize your
binary threshold as best as possible. Remember also that the concrete
color changes several times down the course. This makes calibrating difficult,
so you need to test on each type of concrete. I personally have found calibrating
on the concrete used by the first slope to be optimal for the
IR emitter/detector, but it might have
been circuit specific. To help with calibration, write a small algorithm I like
to call auto-calibration. Basically when you turn on your robot, it reads
a measurement obtained from the white line, and another measurement from the concrete.
Have your algorithm find the average of those two values and set that to be your
binary threshold value. You should do this for each IR sensor because your circuits
will have small resistance variations. Auto-calibration, as opposed to manual calibration,
is great for unexpected weather. Ever notice how concrete changes color when it is
Sunlight can flood sensors to the point of being useless.
Our sun emits large quantities of light in the infrared spectrum, and although
the human eye is blind to it, electronics are not. For obvious reasons the
IR emitter/detector circuit is quite sensitive
to even the smallest amount of sunlight. So it is important to develop a shield
that blocks the light. There have been many variations of this: Cereal boxes,
garbage bags, boxes, electrical tape, black felt cloth (which does not work well), and duct tape to
name a few. Remember, the shield must always be flush with the ground, so it has to
be flexible too. Do not forget to test your shield - take measurements inside and
outside, and if you notice measurement variation, your shield is not good enough.
Hills are a huge control problem.
80% of all MOBOT's that can follow the
white line lose it coming down the very first hill. There are two reasons for this.
The first is speed control. The MOBOT goes down the hill at full speed and cannot
make the sudden sharp left turn at the bottom. This means you need a motor strong
enough to stop your robot, sensors that can update as fast as your robot moves,
and a feedback control system to detect when you are going too fast. Sound too
complicated? Modified servos WILL ALWAYS work for this problem.
But they are too slow to break any speed records. Your other option is to use a
DC motor braking technique.
Good luck. This is a challenge which most contestants fail at, or think they can skip.
The other problem going down hills is that as the slope changes, the angle
that your sensors see the white line changes. This is a huge problem for IR as
a change in distance from the ground can yield significant sensor reading differences.
A solution to this would be to put the IR on a separate suspension system to always
stay level with the ground. Solving this problem will also solve the problem with
cracks in the concrete. Speaking of suspension systems, I have occasionally
seen MOBOT's bottom at at the bottom of the hill because they place IR in the front
of their robot. If you decide to do this, you probably need suspension on your robot.
As additional comments, I have not seen any robot successfully detect the hill, although
it is possible. Mercury switches and
accelerometers have been tried, but often
vibration is too great and hence accidently triggers the sensors too often. Interestingly,
counting hills can be useful for knowing when to turn on your decision point algorithm.
The sensors get a poor view of the course. This goes for both camera
vision and the more traditional IR. Camera placement is very important. Not too high
or too close, not too angled either. Test, don't guess! Also, if your camera refresh
rate is slow, have your camera look slightly ahead. This way it can 'see into the
future' and technically predict when to make a change before it is too late. For
any sensor you must also consider the center of rotation on your robot. Put your
sensors too far away, and when your robot turns the sensors cannot keep up with
the sudden and rapid change. For IR, you must also make a very important design
decision: the placement and number of IR in your array. Optimally you want as many
as possible - a high resolution is why camera vision usually outperforms IR. But
your algorithm gets a little slower and more complicated with each additional IR added.
Plus you need to wire more circuits, and calibrate more through testing. I recommend
to opt for a high resolution of 4-8 IR, but technically it is possible to do
the entire course with just one. I actually have done the entire course with just two,
but I did it out of simplicity and laziness, not optimality. I have posted a few
MOBOT algorithms to help.
Don't bother with it. At least not until you have
already designed a robot that can consistantly do the rest of the course. Too many
contestants try to solve the decision point problem before they figure out how to
survive the first hill. If you can do the rest of the course, the decision points
are fairly easy. I have seen encoders used; electrical, mechanical,
and Sharp IR rangefinder gate counters; and both camera
vision and IR for detecting the line splits. Remember, if you can get to the decision
points, you probably have 1st or 2nd place already.
Fertilizer dust can jam IR.
My last MOBOT is probably the first and only in
MOBOT history to encounter this problem. A week before the competition a layer
of fertilizer dust was sprayed on the grass near the course. Due to a lack of humidity
the dust quickly covered the course. It was in small enough
quantities not to affect readings, however as my robot traveled slowly the dust collected
on the sensors itself.
Within 15 feet my black IR had a thick grey layer
of dust preventing any more line following. I believe it to be statically charged dust,
how else would it stick? My desperate solution, which also got me judge's choice that year,
was to place a high powered fan on front to blow the dust away. The robot would consistantly
go 3x further, but dust was still too bad. Others have also suggested using air canisters
to blow air on the sensors. A month later I retried the course and made it to the
decision points with little dust issues.
I've documented my previous MOBOTS and included video of each following a white line:
2003: Pikachu (video only)
2004: Taurus 2
2005: Fuzzy the Omni-Wheel Robot
2006: Pikachu IV
2007: Line Following Robot
2008: Experimental Robot Platform
Most contestents fail from just a lack of testing and preparation, often waiting
until 3 weeks before the competition to start. If you do this do not expect it to work.
MOBOT can be solved, but only given enough time. So good luck, start early, and
hopefully my guide will save you from mistakes.
If you have ever competed in MOBOT and would like to add your two cents, message me!
Many of you have had interesting code/algorithms you should share.