Search Here

MISC
 Parts List
 Robot Forum
 Chat
 Member Pages
 Axon MCU
 Robot Books
 Shop
 Contact

SKILLS
 How To Build
  A Robot
  Tutorial
 Calculators
 Mechanics
 Programming
 Miscellaneous
 Robots
 Space

HARDWARE
 Actuators
 Batteries
 Electronics
 Materials
 Microcontrollers
 Sensors

SCIENCE
 Robot Journals
 Robot Theory
 Conferences

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 wet?


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.

Decision points. 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.

Working Examples
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

Final Comments
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.

Get Your Ad Here