Congratulations! You've come to the web page for the 2000-2001 UC Berkeley Micromouse project. If you're at all interested in micromouse, I invite you to email me and say that you're interested. Please also tell me how you found out about this webpage. (Thanks!) My name is Tobin Fricke and my email address is tobin@splorg.org.
There's nothing much on this page yet, but I'll post any announcements and so forth here. You might want to read about what we've done so far (including a picture of Jake, our 1999 robot). If you have any questions, please email me.
| Who | You, Me, and the IEEE |
|---|---|
| What | Cal's 2000-2001 Micromouse Kick-Off |
| When | Thursday, September 28, 2000 at 5 pm |
| Where | Moore Room, 2nd floor Cory Hall, in the courtyard |
| Why | Need you ask? |
What is Micromouse? Micromouse is an annual contest, sponsored by the IEEE. The goal of the contest is to build a small robot that is able to drive through and solve a maze. The specific layout of the maze is not known in advance, but its general specifications are: the colors of the walls and floor, the dimensions, etc. The maze is 16 cells wide by 16 cells tall. The "mouse" always begins in one corner and the goal is to reach one of the four center squares. Each team has a $500 material budget for the project.
What are the actual contest rules? Here are the rules for the 1996 contest, thanks to Joshua Cantrell (see below). Of course, these may have changed slightly since then, but the gist is the same. I will post current or at least more recent rules if I find them.
What is the IEEE? The IEEE is the Institute of Electrical and Electronics Engineers, a professional organization for electrical engineers. For more information please see their website. Micromouse at UC Berkeley is supported by the UC Berkeley IEEE Student Branch (formerly known as the University of California Society of Electrical Engineers [UCSEE]). This group's headquarters are in 204a Cory Hall, and you are invited to drop in any time. Student membership in the IEEE costs $19/year.
When and where is the contest? The contest is part of the IEEE Central Area Meeting in the Spring. It usually takes place in the first week of May. The location changes every year. In 1999 the meeting was at CSU Chico, and in 2000 the meeting was at University of Nevada, Reno. (Hopefully it will be at University of Hawaii eventually)
What schools do well in Micromouse? University of Hawaii (yes, they're part of the Northern California Region) and Cal State University Chico have done very well in the past two years. UC Berkeley has never entered the contest, and we'd like to change that.
What skills do I need to participate in Micromouse? First and foremost, you must be willing to learn and experiment. There is no single class at Cal that teaches you everything you need to know for Micromouse; it's a learn-as-you-go sort of thing. We encourage everyone who is interested to contact us. I was part of the 1998-1999 team starting my very first semester at Cal. Fortunately we can divide up the tasks, so not everyone needs to be an expert in everything; people with skills in one or more of EE, CS, ME, or control systems, are particularly helpful.
Here are some things that need work. If any of these sounds interesting to you, please email me.
Simulator: I think it was Professor Wujek who very wisely said, "If it doesn't work in simulation, it can never work in real life." (Of course, assuming your simulator isn't messed up). What we'd like to have is a micromouse simulator. This will be a program that reads in a file describing a particular maze layout. The program simulates the environment of the maze and the interaction of the mouse with the maze. One subroutine will contain the mouse control software -- ideally, exactly the same software that we will run on the actual robot. The simulator will provide this subroutine with data corresponding to the mouse's sensor input, and the mouse will respond with motor commands. The simulator should be able to optionally introduce a variety of errors that will \ likely be present in real life: wheel slippage, spurious sensor readings, non-ideal motor response, etc. This will allow us to develop the micromouse control software in a "clean room" environment before loading it onto the real robot. Furthermore, it will allow multiple people to independently experiment with micromouse control software, and it will allow them to do so before the physical robot is constructed. In Fall 1998 I (Tobin) wrote a piece of software that does a lot of this, but it needs a lot of work before it will be useful -- perhaps a complete rewrite. If you email me I will dig up the sources and executable and send them to you.
Sensors: As obvious as this may sound, the robot's sensors provide its only view of the world. Thus it is very important to choose sensors which provide sufficient information to navigate the maze. It's unclear what the best system is. A popular scheme is to have down-looking infared proximity sensors to detect the walls. But how many sensors are needed, in what density, and what type? It would be incredibly useful to have short-range distance sensors looking side-to-side. Is there an easy way to do this?
Control: This is the big crux of the Micromouse project. How do you keep track of where in the maze your robot is? How do you drive in a straight line, even in the presense of external forces and other irregularities? How do you turn cleanly? We require a control algorithm, and we don't have one right now. Can you help?
CPU Platform: In the past we have used the MC68HC11 as our microcontroller, and it has served us very well. However, perhaps it's time to move to a more powerful processor? What would be the benefits (faster computations, floating point, higher level tools) and drawbacks (learning curve; time to fabricate, learn, and debug new hardware; added complexity) of doing so? Is it worthwhile? What's available?
Motors: Stepper motors, or DC motors? Steppers are heavier, less efficient, more expensive, and are controlled by rotating the axis through discrete steps. DC motors are lighter, use less power, are less expensive, are controlled using PWM, and require an encoder to close the control loop. (At the 1999 contest, virtually everyone used DC motors; at the 2000 contest, virtually everyone used steppers)
more being added as I have time
