Micromouse Outcome – Why I lost, and What I learned

So, after spending a good couple months on the thing, I didn’t get very far, but I sure learned a lot from the whole experience. Now knowing all of my robot’s strengths and weaknesses, as well as all the other competing robots.

The Rush for a Final Product

The last few days before the UCSD Micromouse Competition were pretty hectic. With midterms the previous few weeks, I hadn’t given myself nearly enough time for programming and testing it in our maze. In fact, I hadn’t even finished my flood-fill (maze-solving) algorithm until the Friday before the competition.

By the day before the competition, my robot was able to successfully solve the maze in its head, but it still didn’t move around the maze very well. And this was my ultimate downfall.

The Programming

Here is my repo if you care to see the code. I believe I included all of the libraries I used. All the folders preceded by “Mouse” are my main libraries, the others are all helpers for the implimentation. Please feel free to criticize any of my code, that is, all of the files with my name at the top.

Structure

My main goal was to abstract everything as much as possible, though keeping speed and RAM efficiency a close second priority. I accomplished that decently, though I became dangerously close to running out of RAM with my Maze information.

I began by building reusable classes for each of my I/O devices. The MouseIR, MouseMotor, MouseOutput (using an RGB LED), and PushButton all allow me to easily add any number of these devices by simply instantiating a new one passing in the pin(s) I used. I then built around these abstracting more each time.

The “MouseBrain” library was my outermost, fully abstract functions, used by “MouseBrainExample.ino”. This encompassed both the “Mouse” library, which controls all of the physical movement of the mouse, and the “Maze” class, which held all of its knowledge of the maze its position in it.

Maze-Solving

The main maze-solving algorithm I used was the popular modified flood-fill. I was unable to figure out the supposed way to “generate cell values at runtime” in time for the competition, so I went for the heavy RAM usage method, using two 256 byte arrays to store my walls and the flood values. Luckly, I just barely had enough leftover RAM for everything else.

Its Biggest Weaknesses – Size!

Album of the build.

After months of planning the build without any real testing, I put the whole mouse together in one day, BEFORE the programming. I was naive. While other teams began rebuilding to downsize their bots, I kept telling myself, “Ah it’s a little big, but I’ll just make up for it with good programming.” FALSE. There’s only so much my programming could do to help.

The motor gears were loose enough to give a random and unaccountable error every time it turned, as well as in normal wall avoidance. It only had to be off by a couple centimeters to run into a wall.

Hopes for the Future

Overall, it was a whole lot harder than I expected it to be. I have so many plans for improvement if I get another chance to compete. Including but of course not limited to: