MicroMouse Simulator
Jon Smith
Luke Last
Norwit Veun
Vincent Frey
CSCI 567
Spring 2009
1. Project Overview
1.1.
Description
Our team implemented a MicroMouse simulator. This simulator allows the user to
be able to load a maze and test a maze using a maze solving algorithm. There are default mazes
and also default algorithms that the user can choose from. There are also statistics that display
relevant stats to for the MicroMouse competition. In addition, the user is able to create and save
their own new maze and algorithms.
1.2.
Background
MicroMouse is a worldwide competition of custom designed robots, referred to as
mice, with the goal of getting to the center of a maze the fastest. One of the most daunting tasks
for students starting out is that they cannot get a good visual representation of what the mazesolving algorithms do. Currently there are many websites with snapshots of what the
algorithms do at a given time but here they can not only see what the algorithms are doing but
they can also try their hands at writing their own algorithms.
2. Project Description
2.1.
Model
There are three key models used to implement this project: MazeModel,
RobotModelMaster and RobotBase. The MazeModel describes a maze itself; it tracks the size
of the maze and it stores what walls exist and where. RobotModelMaster describes the mouse
itself; it tracks where the mouse is and where it has been as well as insuring that the mouse
doesn’t make any illegal moves (such as going through a wall). Robot Base is the framework
for the mouse’s intelligence; extensions of this model determine how the mouse should traverse
the maze with varying levels of complexity. There is a class called RobotModel but this class
merely extends RobotModelMaster in a way that custom RobotBase’s cannot violate privacy
expectations of the design; it provides no additional functionality.
2.2.
GUI
The GUI has four distinct views: a simulation view, a maze editor, a custom
scripting area, and a statistics view. The simulation view allows the user to watch a mouse
traverse the maze; RobotBase instances may actually allow the user to see the maze from the
algorithms point of view as can be seen with the Tremaux and Flood Fill examples. Shown
below is an example run of the simulator. The lists on the right show the maze selected and the
algorithm selected. The simulation graphics options allow the user to select how they wish to
see the simulation run. The fog option shows the user what the mouse has seen. The path
option shows the user three different paths: the first completed run to the center, the best
completed run to the center and the entire path run by the mouse. The understanding allows
the user to see the maze from the view of the algorithm; two different data types are supported
for this view – Directions and integers. The classic view shows the maze in a way that is similar
to preexisting samples of maze viewing programs.
The maze editor allows the user to create and save custom mazes of their own design. The
base interface for the maze allows the user to click on walls to toggle their state but, as this is quite
tedious, templates of some common patterns in mazes were created and the mouse may be dragged
while clicked for the user to more quickly build custom mazes. The buttons to select the templates
are rendered with custom icons. The maze editor also shows the user where a maze violates the
rules for American competition maze designs; red pegs are examples of illegal peg instances and the
example below is an example of an Asian competition maze that allows for multiple entrances to the
center square. The second example is one of a custom maze being designed to show how the
templates look during use.
The custom script editor allows the users to design their own algorithms. This will allow
users to not only design their algorithms but also to save them, test them in the simulator and
review pertinent statistics about their efficiency. API Documentation is given to let the user know
what must be implemented to function as an extension of RobotBase. The underlying format for
the scripts is Python; the example below is a Python implementation of a Left Wall Following
algorithm.
The last GUI view is the statistics panel. This panel allows the user to view pertinent statistics
about how an algorithm will react to a given maze. The statistics are fairly self-explanatory except
for one note is that the number of unique squares traversed is important because if an algorithm
cannot solve the maze then its score is determined by this statistic. There is also a maze view
displaying the first and best runs. The example below shows the statistics for a run of Flood Fill.
One side note is that the users may select the look and feel of their choice. Below is an
example of the Windows look and feel.
2.3.
Complexity
Initially there was a plethora of Swing Components in this GUI but eventually these
were thinned down to make the user’s experience more consistent from one view to another.
The MazeView component is the primary custom component, extending JPanel, that the user
will notice but is not the only one. The templates in the maze editing view use recursion to
create mouse oriented graphics that will interact with a MazeView. The primary Swing
Component that the user will interact with is the JList though JSplitPanes, JScrollPanes,
JCheckBoxes, a JSlider, a JTable, a JComboBox, JTabbedPanes, a JToolbar, a JMenuBar,
JMenus, JMenuItems, Boxes, and JButtons also exist.
3. Software Design
3.1.
UML
3.2.
Design Changes
The primary maze view on the simulation panel had to be redesigned for
better performance as it was running much to slow on older computers. The maze
model coordinates where changed from the bottom left being the origin to the top left to
correspond with the maze view. We also took out unnecessary items from the menu bar.
We showed three different paths with different colors to make it easier to see.
3.3. Code Organization
The root level package is called “maze”. Inside that is the Main.java file which
contains the main method and entry point into the application. There are 4 packages
under “maze”. “maze.ai” contains classes related to the robot mouse AI algorithms.
Inside that is a package “maze.ai.python” which contains python scripts used as new
file templates. The package “maze.gui” holds all the swing graphical classes and the
different main panels. PrimaryFrame.java is the master JFrame. Subpackages are an
images directory in “maze.gui.images” and the maze editor classes in
“maze.gui.mazeeditor”. The “maze.model” package contains data model classes for the
mazes, robots, and views. Inside that is “maze.model.mazeExamples” which holds some
default maze files. Finally there is the “maze.util” package which just holds general
purpose utility classes. Currently it has some classes used to implement the listener
design pattern.
3.4.
Algorithms
The provided instances of RobotBase each had their own distinct methodology. The
Left and Right Wall Followers follow the Pythagorean method of traversing a maze that
suggests that you will exit any maze just by always keeping your hand on the wall. These
methods work when dealing with a maze that is of the “enter and escape variety” such as a
hedge maze but a proper MicroMouse maze will put the goal on an island an make these
algorithms useless for solving. Some examples given did not make the goals islands so the Wall
Followers still succeeded; even a blind squirrel finds a nut every once in a while.
The French mathematician Tremaux developed an algorithm similar to the Wall
Followers that is explained using an example from Greek Mythology. When Daedalus
constructed the Labyrinth on Crete he simultaneously created a magical ball of string that
would unravel from the start of the maze to the central room that housed him and the
Minotaur. Tremaux’s algorithm uses this concept of a ball of string, just with less magical
inspiration and more perspiration. Unraveling the ball of string as you traverse the maze,
follow the wall with your right hand on the wall; any time you come across an intersection that
you have already visited you back track along you line of string until you come to an
intersection that has an option that has not been explored and then explore that avenue. While
implementing it doesn’t require this much complexity, it can be shown that this breaks a maze
into a graph and then traverses it as though it were a tree using a depth first algorithm.
The Flood Fill algorithm is the standard choice for MicroMouse. It is basically a
variant on Dijkstra’s shortest path algorithm. You start by asserting your goal(s) is/are zero
distance(s) and all other cells’ distances are infinite, for this implementation at least, and load
the goal(s) into a queue. While the queue is not empty you pop the head of the queue and recall
its distance. For each neighbor of the head of the queue you determine, by your present
knowledge of the maze, if it is physically accessible (if a wall is present) and if the head’s
distance is much less than the neighbor’s distance then set that neighbor’s distance to one
greater than the head’s and push the neighbor into the queue. When implementing speed runs,
secondary runs that only traverse to the center using previously explored cells, you also check
to see if the neighbor has been previously explored and if the current goal is the center; speed
running mice still explore on the way back to the start.
4. Implementation
4.1.
Subdivision
The primary design divisions were Luke handling the Simulator and Scripting, Jon
handling the Maze Editing and Customizations, Norwit handling the Menus and associated
Dialogs, and Vince handling the models for the Maze and Maze Solving algorithms and the
Statistics View. Everyone dabbled in each other’s areas for the minor enhancements. For
example Luke, as a side effect of his design responsibilities, dictated a revised structure for the
models so that they would work more fluidly with his designs.
4.2.
Communication
The project was placed on Google Code as an Open Source project, allowing for
easy file sharing, a forum for issues and revision control. The group was able to meet after class
and in the library as needed but the primary communication of work was through the Google
Code site.