"SMACK!"
Written by: Steven Kibler
Edited by: David Giessel
“Smack”, “scrape”, “rub”, “bump”, “slip”, “skid”, “out-of-control”, “ooof”, “D’oh”, are commonly heard phrases in my group. These phrases are occasionally accompanied by cheers of success, no matter how small the feat, though these are much more infrequent than we would prefer. Now, if you’re thinking that my group is a participating team in the X-games street luge competition, you’re on the wrong track. Try again? This time, think of two very little tires, a couple tiny electric motors, three very small batteries, a dime-sized processor, and miles of wire connecting it all. Add the talents of three budding engineers, and a bolt of lightning, and you’ve got….
MICROMOUSE!!!

I am not joking when I refer to the phrases above as being common around our group. We were guaranteed to be saying at least a couple of those phrases every hour! As simple as the task seems, making the mouse drive in a straight line, without touching walls, and making smooth, perfectly square turns, is not accomplished without many cross-eyed stares at the computer screen, groaning under the strain of having to think hard. “Well, really now, how hard can it be”, you ask? Why not just apply the same voltage to each of the motors to move straight forward, and equal-but-opposite voltages to make the mouse pivot in place for a square turn? Well, that’s what I intend to answer in this article. There will be very little technical detail here; just simple theory and discussion on what we tried on our mouse, and why it did or did not work for us.

It turns out that, due to small imperfections in each motor, placing the same voltage across two identical motors will result in two different speeds. Their speeds might be close, but when you’ve only got a couple centimeters between the wheel and the wall, close is not good enough. A sure fire way to hear the sound of the mouse cracking its skid plate against a wall is to trust your motors to be “close enough” with the same voltage! It’s not a pleasant sound, and if not corrected, neither the mouse nor the walls will be thanking you! So, if it is not possible to just load a voltage and trust the motors to be correctly turning at equal speeds, how do we know what voltage to load to it? We have to use some outside reference to determine what our mouse is doing, then use that information to make the decision on how to control our motors. This is known as feedback. So what outside references are useful to us? Most obviously would be the mouse-loving walls. These walls are tricky little devils; calling and luring your mouse like sirens calling to sailors, “Come to me, come rub my smooth walls, you’ll like it I promise!” It’s not hard to see that with their looming presence over the mouse, the walls are great references to use for control. While I make them sound like mouse magnets (in fact, our mouse LOVED the walls and wouldn’t ignore their siren calls), the walls are almost always present in the maze, and because we must map them for the maze anyway, they are a convenient object from which to detect our distance and drift to decide how to control our motors. So, by giving the mouse eyes, it can detect its distance from the walls, and adjust its wheels accordingly. I did, however, say “almost”. There is at least one maze condition in which there are no walls on any side. One example is a cross-road, where two hallways cross. The other is an area we lovingly refer to as a parking lot; aptly named because that is exactly how it looks, with “parking stalls” on both sides of the hallway. These parking lots can be many stalls long, and there are no walls to detect and correct from. In this case, we must rely on our mouse to move straight without reference from its eyes. In this case, we could look at the speeds that its wheels are moving, and use that as feedback to determine the proper voltage to be applied to the motor. Using wheel speed data as feedback, the mouse will run much straighter through the hallway, allowing it to move faster and use its eyes less. So now we have two forms of feedback; the data it gathers from its eyes, and the data it gathers from its wheels. Let us explore each form of feedback individually, along with its correction algorithm, and after that we’ll combine them to show how the two work together.

Consider this example; you’re driving your car down the highway, on one side is a concrete wall and on the other is a concrete barricade dividing the opposite-moving lanes. You’re driving straight, and are positioned evenly between the two walls. At first you aren’t making any corrections; you’re going straight and don’t need any! Well gradually, due to imperfections in the tires and the road, your car begins to drift toward the right wall. Your eyes detect both the rate of drift toward the wall (the speed you are approaching the wall), as well as your absolute distance from it. Detecting (seeing) those two pieces of information allow you to then correctly use your steering wheel to reverse your drift, continuing your correction until you’re moving back toward the center of the lane. When your velocity back toward center is acceptable, you stop correcting and let the car drift back toward the center on its own. Then, just before getting to center, you use your steering wheel again to straighten up, and you’ve just correctly regained your center position, which lasts until those pesky imperfections cause you to drift again! This is a never ending process, and you’re making tens or even hundreds of corrections every minute. The mouse, on the other hand, is capable of making thousands of corrections every second! Programming this “driving” algorithm into the mouse will keep the mouse from hitting the walls, and is pretty good at it. Is that all there is to it, though? Realize you’re drifting and correct? In fact, we won our first competition using only this algorithm! But by itself, it is not a perfect algorithm. Apparently, Micromouse eyes are not very good. Sensors that are used for mice (mostly infrared (IR) diodes and corresponding IR light-to-voltage sensors) cannot be trusted to give accurate information under every condition. For example, try holding an IR sensor at a set distance away from a wall at exactly 90 degrees, so that most of the light from the diode bounces back to the sensor, and read the voltage that is returned from the sensor (this voltage corresponds to the distance away from the wall). Next, without moving away from the wall, change the angle, perhaps only as little as 5 or 10 degrees. Now, even though you’re still exactly the same distance from the wall, the sensor will say you are much farther away. This inconsistency, along with others (ambient light for example), makes it nearly impossible for the mouse to correctly see its exact distance from the wall and its rate of drift, which in turn makes it nearly impossible to get the mouse to center itself and stay in the center. Instead it behaves like a real mouse that just did an overnight splurge on some really stinky, fermented cheese; it weaves and wobbles around center, at times overcorrecting and bee-lining it straight toward the wall, just barely correcting in time to avoid leaving a skid-mark! Not only does this make the mouse look sloppy, but it also limits the ability to speed the mouse up (its wheels start tripping over themselves)! Conclusion: using the mouse’s eyes as its sole source of feedback works, but is not very effective, at least without some extremely complicated and lengthy algorithms. So is the wheel speed feedback any more effective by itself?

How does a blind mouse get around? In addition to its other senses, it also has an innate idea of where its limbs are without having to see them (close your eyes, and you can still touch your nose). In a controlled environment (such as a maze where all walls are exactly 18 cm apart), it is possible for a mouse to move from one wall to another simply by counting its footsteps and having experience in how far each step takes it. It is the same with Micromouse. If you attach a sensor that allows you to determine how much the wheel has turned, and knowing the wheel’s size, it is possible to know exactly how far the mouse has driven. In addition, if you keep track of time, and know how much time it took to turn the wheel that amount, you are then also aware of the mouse’s speed! The blind mouse, knowing how many steps it needs to get to the next square of the maze, will get to that square provided it begins its journey pointed straight at it, and moves its legs at identical speeds! So it is with the Micromouse; start it straight, ensure the wheels turn at identical speeds, and keep track of the amount its wheels turn, and you can move from one square to another without having to correct off the walls. This is an advantage because, as I mentioned earlier, there is no guarantee that a wall will be present for visual correction. Also, one of the true beauties of detecting wheel speeds is that the algorithm can be written in a way that eliminates problems due to differences in the motors. As mentioned above, it is impossible with the same voltage applied two motors to achieve exactly the same speed. But if we know the speed, and we use it as feedback, then we can write a simple algorithm that changes the voltages independently, based on the current wheel speed. If one wheel is turning faster than our target speed, then it can lower the voltage of that motor in small increments until the correct speed is achieved. Likewise, if the other wheel is turning slower than our target speed, then the processor can increase the voltage in increments until corrected. Because the processor is so fast, it is capable of making many “small increments” very quickly, so no matter how far off the wheels are from their target speed, the processor can correct the speeds nearly instantaneously! This algorithm for control creates much smoother movements and straighter lines, as compared to the visual only routine that relies on the IR sensors. Unfortunately, though, there are also imperfections in the wheels themselves and in the board the mouse runs on, so even with perfectly identical wheel speeds, we cannot expect the mouse to run perfectly straight in the maze! Because of this, it is necessary to use both algorithms jointly to control the mouse smoothly.

Which algorithm, though, should have the most weight, or the most control, of the mouse? They cannot be equal, because in fact the two algorithms will fight each other if one is not suppressed and the other prioritized. As an example, if both are equally weighted, when the visual algorithm tries to correct because the mouse is too close to the wall, it increases the speed of the wheel closest to the wall, causing the mouse to turn away from the wall. However, the speed algorithm detects this change in wheel speed and decreases the speed of the wheel again. Obviously, then, the two algorithms, like brothers, will not play nicely with each other! We have to separate them, and only let one play with the mouse at a time! Which one first? If it is not obvious, let me just say that there is some debate as to which algorithm should take priority. Some of us believe that it is better to leave the visual correction on most of the time, and have the wheel-speed algorithm running in the background, only working when the visual correction algorithm has no input. The rest of us believe that it is better to let the mouse run as straight as possible as long as possible, only making visual correction based on getting too close to the wall, at which point the mouse makes a very swift correction back to the middle (based on its visual algorithm), and once centered, the wheel-speed algorithm takes over again and runs straight again for as long as possible.

So which is best? I leave this for you to investigate and decide for yourselves. I also believe that what works best will depend largely on individual circumstances; things such as mouse design, experience, and the software-writing abilities of the group members. Try each one individually, see how each works on its own, and investigate the merits and demerits of each, then combine them in a single algorithm that efficiently utilizes all the merits of both and none of the demerits.

On a final note, in recognition that there are incredibly bright people reading this, I would like to add the disclaimer that there are many possible solutions to the control of a two wheel robot. The algorithms I mentioned above are merely our work-in-progress solutions to the problem. I strongly encourage any Micromouse team to experiment with outside-of-the-box ideas they might have as time permits. It is very possible that you could discover a solution that completely surpasses anything being done today! Go and experiment, toss ideas around, learn, and most importantly, HAVE FUN!!!