The Intellimouse Explorer: An Intelligent Way to Solve a Maze
V. Fucsko, B. Houle, H. Mitro, M. Olson
Abstract – The micromouse competitions have
been running since the 1970s all around the
world. The modern competitions however
originated in the 1980s. A modern competition
maze consists of 16 by 16 cells. The “mouse”, an
autonomous robot, must find the center of the
maze in the smallest time possible. The mouse
must track of the path traveled and not destroy
the maze at any time. The competition rules are
based on the IEEE APEC Micromouse
regulations.
I. Introduction
The Intellimouse team successfully designed
and tested a working micromouse prototype that
conforms to the IEEE APEC Micromouse
contest rules. The design integrates a Handy
board microcontroller board, two stepper motors,
and twelve various sensors to allow the
micromouse to autonomously navigate a given
maze. The design was completed well under
budget (See Section VII) and was successfully
demonstrated at a Northwest-area IEEE
sponsored competition.
Analysis of the
micromouse’s hardware reliability and its
product lifecycle are included in this report.
Additionally, we included a “future work”
section detailing our recommendations and
experiences for the benefit of any future teams
that may continue the project.
The goal of the Intellimouse Explorer
project was to design a self-contained,
autonomous, electrically powered vehicle called
a “micromouse”, to negotiate a path to the center
of a maze. We built micromouse in accordance
with the IEEE APEC micromouse Contest Rules.
A. Specifications
The micromouse must be self-contained and
fit within a 25-cm square area. The maze is
comprised of a 16 x 16 array of 18-cm square
blocks with white, infrared reflective walls and a
black, infrared absorbing floor. The tops of the
walls are red. The micromouse starts in a corner
of the maze, searching for the goal in the center
of the maze. After finding the center of the
maze, the micromouse remembers the course it
traveled. It then begins a “speed run” in which it
returns to its starting point and navigates its way
back to the center of the maze in the minimal
amount of time. During this process, the
micromouse
operates
without
outside
intervention.
II. Procedure
A. Microcontroller
The microcontroller is the brain of the
micromouse. It controls everything the
micromouse does while in the maze. Based on
the inputs the microcontroller receives from the
sensors, it calculates a path for the micromouse
to navigate the maze. It also controls the drive
motors to move the micromouse, and after
reaching the goal, optimizes its path to the
starting square. The microcontroller board is
low power and the entire board is smaller than
9x12cm. We also desired a microcontroller that
is C-programmable and user-friendly. Based on
these requirements we decided to use the MIT
HandyBoard, a Motorola 68HC11-based
microcontroller. We broke down the work on
the microcontroller into three different functions:
path finding, movement, sensing. The path
finding algorithm receives inputs from the
sensors, calculates the best move, then the
movement algorithm outputs commands to the
motor drivers. The micromouse navigates the
maze using the sensor wing for guidance; the
sensor wing detects when the micromouse is offcenter, and makes minor corrective adjustments
to the micromouse’s heading.
B. Drive System
The micromouse's drive system consists of
two stepper motors, using ball casters for balance
(as shown in Figure 1). The micromouse turns by
rotating the motors opposite directions, allowing
for 360° turning in a single cell of the maze.
Acceleration dynamics play a larger role in the
micromouse’s maze solving time than its top
speed because of general maze design. Based on
a worst-case analysis of the maze with our time
goal of 10 minutes for a run, the motors must
accelerate the micromouse at 0.8 m/s/s and drive
the micromouse at an average speed of about 0.1
m/s. According to these criteria, we chose the
ReliaPro 42BYG stepper motor. It is a high-
Fucsko, Houle, Mitro, Olson
2
torque stepper motor, which gives plenty of
acceleration for dynamic operation.
The Handyboard integrates many functions
that simplify the drive system design process.
The Handyboard contains an onboard motor
controller and built-in libraries, which allowed
us to directly connect the motors to the Handy
Board without developing extra control
algorithms. The motors are rated for 6-12V at
under 1.25A each, meaning that the motor can
draw its power directly from the Handyboard’s
power supply.
C. Sensors
The micromouse uses two types of sensors,
analog and digital. It is equipped with a row of
eight Fairchild QRB 1134 proximity sensors
overhanging the top of the maze in a “sensor
wing” on both sides of the micromouse to keep
the micromouse centered within the cell and to
map the environment in adjacent cells. These are
digital sensors, which output a one when they
detect a wall and zero otherwise. We use Sharp
GP2D120 short-range distance sensors and
Sharp GP2D12 long-range distance sensors to
detect the length of the path in front and to the
sides of the micromouse. These infrared sensors
are low cost, high resolution sensors, and have
been used effectively in several micromouse
designs. They transmit an output proportional to
the distance to the nearest object within a range
of 10 to 80 cm. The sensors are minimally
affected by reflectivity and surrounding lights.
Therefore, we calibrate the sensors to function
predictably for varying maze and ambient light
conditions.
Figure 1: Chassis Side View
The chassis required two wheels with
sufficient traction to avoid slipping, and two
caster wheels for balance. The GMPW wheels
are made to match almost any DC or stepper
motor. The wheels are molded from ABS
(Acrylonitrile Butadiene Styrene) plastic, and
they measure 58mm across by 7.62mm wide. It
uses a rubber tire that increased the total wheel
diameter to 60mm and dramatically improved
the wheel’s grip. Two Tamayi, Inc. ball casters
(shown in figure 2) balance the micromouse.
These casters attach directly to the micromouse
housing using standoffs to place them at the
correct height.
III. Systems
A. Chassis Design
Figures 1 and 3 show the micromouse
chassis design. We used the Handyboard’s builtin plastic housing for the base of our chassis,
attaching the motors and ball casters directly to
it.
Figure 2: Ball Caster
Figure 3 below shows the sensor mounting.
Fucsko, Houle, Mitro, Olson
Bottom View
1
2
3
4
1.8
11
3
Ball Caster
M
4
Sensor
Wings
5
6
7
8
Figure 4: Sensor Wing Function
*All values in cm
Figure 3: Sensor Position
The distance sensors attach to the front of
the motors and the sides of the ball casters as
shown in figure 3. The distance between each
proximity sensor is approximately 10mm, and
the wing is 24cm long. The wing is composed of
wooden dowels attached to the front of the
chassis. The front sensor wing holds the eight
QRB1174 Infrared proximity sensors 25 mm
from the front of the microcontroller and 2mm
from the top of the walls of the maze. They form
a line directly above a forward wall when the
mouse sits in a cell. These sensors minimize the
micromouse error during straight-line movement
and detect dead end paths.
B. Centering
The micromouse uses a very simple
proportional response control system to keep it
centered within a cell. When the micromouse is
centered, sensors 2 and 7 (see Figure 4) will see
a wall. If the micromouse veers slightly from its
course, sensors 3 or 6 see a wall, indicating that
the micromouse should make a minor adjustment
toward the middle of the path.
If the
micromouse veers far enough from the path that
sensors 4 or 5 see a wall, the micromouse will
make a large turn toward the center.
This centering algorithm works very well for
dense mazes and on long straight paths. While
reducing the number of walls in the maze hinders
the response of the centering algorithm, the tests
indicate that the micromouse still centers
adequately in sparsely populated mazes.
IV. Hardware Reliability
In order to determine the feasibility of mass
producing our micromouse design, we looked its
potential failure modes. After a detailed analysis
of our design, we organized the failure types into
three categories: Handy Board Failures,
Electrical Failures, and Mechanical Failures.
Component Severity
Failures
Handyboard
Occurrence
Reparability RPN
32K SRAM 8
Mem. Latch 8
2
5
3
2
48
80
6811Motorol 8
a
16x2 LCD
3
1
4
32
3
4
36
Passive
5
3
1
15
Active
5
3
1
15
Power Adp.
7
3
2
42
LEDs
2
4
1
8
Motor
Drivers
Buttons
8
3
3
72
4
1
5
20
Trace Failure 7
2
9
126
Electrical
8 AA NiCad 8
5
2
80
Sharp Sensor 4
7
1
28
Prox Sensor 2
7
1
14
5
1
20
1
1
3
1
8
64
Mechanical
GMPW
4
wheel
Glue
3
Stepper s
8
Table 1: Potential Failure Modes
Fucsko, Houle, Mitro, Olson
We calculated the failure mode and effect
analysis (FMEA) using three ratings based on a
10-point scale, with higher scores indicating
increased risk. The three ratings are severity,
occurrence and reparability. The severity rating
is an estimate of the severity of the repercussions
of a given failure. The occurrence rating is an
estimate of how often a failure type might occur.
The reparability (use detectability) rating is an
estimate of the difficulty in compensating for a
given part or failure type. The product of the
above ratings will provide a risk priority number
(RPN), which prioritizes the sub-modules that
need improvement.
Figure 5 shows the Fault Tree Analysis of
the Intellimouse Explorer. These values are
estimates based upon a production volume of
10000 units. This analysis shows that our
product has a 4.47% failure rate, meaning that
447 out of 10000 will be defective.
Figure 5: Fault Tree Analysis
4
B. Maturity
The market for the micromouse is very
limited and would rapidly saturate. While the
sales of the current iteration of the micromouse
begin to dwindle, we can make software and
hardware improvements to the micromouse to
produce an improved version for future sales.
See the Future Work section for details on
possible improvements to our current design.
C. Decline
Eventually the market for the micromouse
will drop below the profitable level and the
product will be discontinued. To extend the
project’s life, we can continually introduce new
versions of the design.
D. Disposal
Although all of the components in the
micromouse can be discarded when they fail,
most of them can be recycled through various
means. The battery pack is a set of NiMh
(Nickel Metal Hydride) rechargeable batteries
shrink sealed in a plastic coating. Disposal of
NiMh batteries into normal waste is allowed but
many battery disposal facilities exist that will
recycle the components of the batteries. The
circuit board can also be recycled, but electronic
component recycling in the United States is still
a developing technology and may not be readily
available in most areas.
V. Project Life Cycle
VI. Test Results
The product lifecycle analysis outlines our
plan for the micromouse’s release into the
market after we complete the design phase.
We verified that the micromouse operates in
accordance with the specifications using the
procedures
outlined
below.
During
development, we tested each of the subsystems
individually. After we completed the design, we
verified the system performance as a whole. The
desired characteristics and the guaranteed
specifications of the design are summarized in
Table 2 below.
A. Introduction to Market and Growth
Once the product is released, we will need to
provide customer support. Since our design
team is small, the most efficient way of
supporting the users is to ensure that we supply
adequate documentation to the user. Since the
micromouse will most likely be used by high
school students to learn about the different
components of robotics and by robot hobbyists
who wish to start with and improve a base
design, we will include a copy of Interactive C
with the product. Interactive C gives the user the
ability to modify certain aspects of the
micromouse’s code during runtime. We will
provide a troubleshooting guide, project ideas,
the code we developed in testing, and our
development tools.
Fucsko, Houle, Mitro, Olson
5
Measured Characteristic
Straight-Line Movement
(w/out sensor feedback)
(1)Variation in distance
1
(2) Perpendicular
(3) Velocity (m/sec)
3.3
3
29
0.1
0.12
Turning
(4) Variation in degrees
(5) Angular Velocity (deg/sec)
1
0.8
120
130
infinite
75
Micromouse in Maze
(6) Num. steps before collision
(7) Average steps to solve
175
60
(8) Average time to solve
N/A*
2.14
10
3.73
N/A*
2.13
175
133
(12) Max steps to solve maze
N/A*
578
(13) Ave. turns to solve maze
(14) Ave. time to solve maze
(min)
(15 Mazes solved within time
limit (%)
N/A*
129
N/A*
4.9
100
81
25
14.5
(9) Maximum time to solve
(10) Average time per cell (sec)
Micromouse in Software
(11) Average steps to solve
maze
General
(16) Max Length (cm)
(17) Max Width (cm)
25
24.5
(18) Min Battery Life (min)
15
> 60
(19) Max Code Size (Kb)**
16
10.3
Percent of All of Mazes
Maze Solver Performance
Original
SpecificationsTest Results
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
Dense Random Mazes (10,000)
Competition Mazes (44 Total)
Less Dense Random Mazes (10,000)
0.5
2.5
3.5
4.5
5.5
6.5
7.5
8.5
9.5 10.5 11.5 12.5 13.5 14.5
Time to Solve (min)
Figure 6: Maze Solver Performance
Figure 6 above shows the performance of
the solving algorithm on three different types of
mazes. The average solving time is 5 minutes per
maze. However, there are mazes that the
Intellimouse is unable to solve in less than 10
minutes due to the complexity of the maze and
its maximum velocity of about 0.1 m/s.
B. FloodFilling
A modified floodfill algorithm is used for
navigating the maze. Floodfill “floods” the maze
assigning each square with the number of moves
it would take to reach the goal from that square.
Because the value of the squares indicates their
respective distances from the goal, the mouse
always moves to the neighbor with the lowest
value. As the mouse discovers more of the maze
the values of the squares change to represent the
new distance from the goal. An example is
shown below in figure 7.
Table 2: Test Results
A. Software
The software consists of the hardware
interaction and maze solving components. We
designed a random maze generator and statistical
testing functions to test various maze solving
algorithms. To test the algorithms thoroughly,
the test mazes contain dead-ends, stair-step
diagonals, loops, and multiple possible paths to
the center goal. We tested our maze-solving
algorithms on over 100,000 mazes without
failure. The average (11 steps, maximum (12
steps, and average number of turns (13 are
shown in Table 2. In addition, we used the
straight-line and angular velocity data to
determine the distribution for the amount of time
it takes to solve the maze vs. number of mazes.
The average time to solve the maze (14) and the
percent of all mazes that could be solved within
the ten-minute time limit (15) will be calculated.
1.5
Seen Maze 1
0
1
2
3
4
8
7
6
5
6
0
7
6
5
X
3
1
6
5
4
3
2
2
5
4
3
2
1
3
4
3
2
1
0
4
Seen Maze 2
0
1
2
3
4
8
7
6
7
8
0
7
6
5
8
X
1
6
5
4
3
2
2
5
4
3
2
1
3
4
3
2
1
0
4
Figure 7: Maze Solution
In this simplified example the goal is
the square located in the lower right of the maze
at (4, 4). If the mouse is located at (1, 3) with
the information shown in Figure 7 Maze 1, the
mouse will move down to position (1, 4) because
its value of 3 is the lowest of its neighbors [3, 5].
Once it moves to (1, 4) it sees the wall blocking
its path to the goal. The grid is flooded to
indicate the new information and the mouse
again will move to the lowest value neighbor, the
8 at (1, 3). This process continues until the
mouse reaches the goal.
Fucsko, Houle, Mitro, Olson
1. Biasing
An issue that becomes apparent once the
mouse is running is what to do when two
neighbors exhibit the same value. The order in
which the equal values are chosen can have a
significant impact on the time to solve certain
mazes. The biasing system we used is illustrated
in Figure 8.
Equal values are chosen based on the
quadrant the mouse resides in. These priorities
are represented by ordered matrices.
For
example, the matrix for quadrant one is [3, 1, 0,
2]. The numbers represent directions in a
clockwise direction starting with zero being up.
Therefore the preferred directions would be [left,
right, up, down]. Using Figure 3.4 we can see
that
the
mouse
favors
an
overall
counterclockwise rotation about the maze. There
is no definitive reason for the counterclockwise
biasing, clockwise would work just as well on
random mazes.
The maze originally
programmed for however, favored a counter
clockwise bias.
C. Drive Systems
The drive system consists of the motors and
wheels and its purpose is to move the
micromouse in the desired direction. Differences
in the straight-line distance traveled for a given
number of steps was measured. The mouse was
directed to travel 674 steps (288 cm), which is
equal to the full length of one side of the maze.
This operation was repeated 10 times, and the
actual straight-line distance traveled (in the
intended direction) was measured for each
iteration. The average distance traveled, as well
as the maximum percent deviation from the
average, recorded in (1), were calculated. The
centering error of the mouse was also measured
as a ratio of the distance traveled perpendicular
to the straight-line motion and the straight-line
distance traveled (2). The mouse traveled
almost 30% of its forward distance to the right,
6
due to the placement of the front ball caster on
the right side of the mouse. However, this error
is corrected by feedback from the sensors in the
complete system. The actual distance traveled
by the mouse (calculated from the straight-line
and perpendicular distances using the
Pythagorean theorem) was used to calculate the
average velocity of the mouse (3). The amount
of turning variation (4) and angular velocity (5)
were also measured using the same process
described above for straight-line motion, with
the mouse directed to turn 360o for each
iteration. Small errors (less than 3%) are
inherent in the stepper motors and the small
variation in the size of the wheels, and can be
detected by the sensors and corrected. Larger
errors are most likely due to a misalignment of
the wheels. A wheel may not be drilled
perpendicularly, or it may not fit tightly on the
shaft of the motor.
D. Sensors
The micromouse uses three types of sensors:
QRB 1134 proximity sensors, Sharp GP2D120
short-range distance sensors, and Sharp GP2D12
long-range distance sensors. We tested the
calibration curves of distance to wall vs.
microcontroller output for the Sharp analog
distance sensors. These curves can be found in
the Appendix. The proximity sensors are digital
and have an optimum detection distance of 0.2
inches. When attached to the sensor wing, the
proximity sensors return a one value if there is a
wall directly underneath.
E. Battery
The micromouse contains eight nickel
metal-hydride batteries that must provide power
to all of the components of the micromouse for
at least the full ten-minute competition time. To
test the battery life, we created a test program
read the sensors, performed calculations, and
moved the motors. The micromouse ran for over
an hour, at which point we artificially stopped
the micromouse.
We determined that the
batteries are capable of providing far more than
the required power to the micromouse. (19)
F. Complete System
The micromouse was tested in 14 maze
configurations. These mazes contain all of the
desired characteristics described in the software
section above. We used these tests to determine
the following:
• The number of unrecoverable collisions. (6)
• The average time to solve the maze. (8)
Fucsko, Houle, Mitro, Olson
• The maximum time to solve the maze. (9)
• The average time per cell. (10)
VII. Budget
The Intellimouse team went well under budget,
as shown in Table 3.
Component
Estimated Cost Actual CostDifference
MIT Handy Baord
$350
$305.00
$45.00
Stepper Motors
$45
$43.64
$1.36
Sensors
$60
$102.75
($42.75)
Mouse Chassis
$20
$2.55
$17.45
12 Pack NiMH
$35
$0.00
$35.00
Battery Charger
$20
$0.00
$20.00
Maze
$60
$170.31 ($110.31)
$79
$0.00
$79.00
Passive Components
Active Components
$100
$0.00
$100.00
Printed Circuit Board
$200
$0.00
$200.00
Report Copies
$25
$47.40
($22.40)
$0
$25.00
($25.00)
Wheels & Ball Caste
Memory Latch
$0.45
$0.45
$0.00
32K SRAM Memory
$5.49
$5.49
$0.00
TOTAL
$1,000
$702.59
Remaining Budget
$297.35
Table 3: Intellimouse Budget
VIII. Future Work
While our design functions within
specifications, it still has many avenues for
improvement. For example, the sensors tend to
report phantom walls if the micromouse is offcentered. In order to minimize this error we
could use a “vote check” sensing algorithm.
Vote checking samples the sensors many times
per cycle or samples the sensors against each
other to determine the presence of a wall. Any
discrepancy in the sensor data will cause the
micromouse to throw out its erroneous data and
recheck the area for a wall. This method can
increase the time it takes to sense walls;
however, it will vastly improve the accuracy of
the micromouse.
The Handyboard has a small amount of
memory, which limits our ability to solve the
maze.
We found that if the micromouse
encounters a very long dead-end path, the
floodfill algorithm recursively searches down
that path and runs out of memory. Using a larger
memory pool would fix this problem.
Our final problem comes from our physical
design and connections. Currently, we connect
the sensors to the Handyboard using wire
bundles. These connections are very unstable
and susceptible to noise. Designing a PCB
7
sensor wing would not only improve the
connections and physical reliability of the sensor
wing dramatically, but would also allow us to
use much smaller sensors.
The following ideas would require a
significant rework of the micromouse design, but
may considerably improve the micromouse:
• Bidirectional control – Allow the
micromouse to run forward or backward,
rather than turning 180°.
• Four drive wheels – Using four-wheel-drive
improves the micromouse’s acceleration and
traction dramatically.
• DC motors – While DC motors are more
difficult than stepper motors to control, they
provide much faster speed.
IX. Conclusion
Although we ran into our fair share of
difficulties ranging from complete hardware
failure to small software bugs, we feel that we
successfully designed and tested a working
micromouse prototype that conforms to the IEEE
APEC Micromouse contest rules.
X. Bibliography
[1]
“Applied Power Electronics Conference
and Exposition (APEC) micromouse
Contest Rules,” [Online document],
1996 Mar 7, [cited 2005 Mar],
Available HTTP: http://www.apecconf.org/APEC_micromouse_Contest_
Rules.html
[2]
Douglas W. Jones, “Control of Stepping
Motors,” [Online], 2004 Sep 21, [cited
2005
Mar],
Available
HTTP:
http://www.cs.uiowa.edu/~jones/step/
[3]
Pete
Harrison,
“micromouse
Information Centre,” [Online], 2004
Mar 4, [cited 2005 Mar], Available
HTTP:
http://micromouse.cannock.ac.uk/
[4]
Fred Martin, “The Handy Board
Technical Reference,” [Online Manual],
2000 Nov 15, [cited 2005 Mar],
Available
PDF:
http://handyboard.com/techdocs/hbman
ual.pdf
Fucsko, Houle, Mitro, Olson
APPENDIX A: An Intelligent design to solve a maze
Start
LookAround
ChooseDir
Better
Neighbor?
Yes
No
Flood(Position)
TurnTo
StepForward
No
Offcenter?
No
Yes
Turn
No
Full
square?
Yes
Goal?
Yes
End
Figure 9: Floodfill Flow Chart
8
Fucsko, Houle, Mitro, Olson
Start
Moves < 43
yes
No
Wall front?
Analog(4) > 100
No
yes
Shift left?
Digital(12) &&
!Digital(8)
Update position
yes
End
Turn Right
Turn(1, 1)
No
Shift right?
Digital(7) &&
!Digital(13)
yes
Turn Left
Turn(0, 1)
No
Way left?
Digital(10)
yes
Swerve Right
Turn(0, 5)
No
Way right?
Digital(10)
yes
Swerve Left
Turn(0, 5)
Figure 10: Intellimouse Control Algorithm
9
Fucsko, Houle, Mitro, Olson 10
Percent of All of Mazes
Maze Solver Performance
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
Dense Random Mazes (10,000)
Competition Mazes (44 Total)
Less Dense Random Mazes (10,000)
0.5
1.5
2.5
3.5
4.5
5.5
6.5
7.5
8.5
9.5 10.5 11.5 12.5 13.5 14.5
Time to Solve (min)
Figure11: Floodfill Algorithm Performance
Fucsko, Houle, Mitro, Olson 11
APPENDIX B: A New Approach to Maze Solution
Modified Floodfill Algorith with Bias
Another modified flood fill algorithm has also been implemented. Using this
algorithm, the mouse is biased to move toward the center on the longest straight-line path
possible, unless the next cell in that direction has been visited too many times. In this
case, the mouse prefers to move away from the goal to explore other possible paths. At
each intersection, the algorithm floods all the known paths to eliminate dead ends,
identify if a known path to the center exists, and decide the next move. Figure 9 below
shows a flow chart of the algorithm.
Start
Initialize
while(!found goal)
Flood possible paths
Decide
move
no path
found
Dead end,
go back the
way we came
Go forward until
intersection
NO
Goal?
YES
Finish
Figure 12: Modified Floodfill with Bias
With information from the distance and adjacent wall sensors, the mouse is able to
identify dead ends without visiting all the cells. However, this algorithm heavily relies
on accurate sensor data. The mouse will never revisit a cell which it believes to be a dead
end, so it may not have an opportunity to correct a wall that has been misidentified. The
efficiency of the algorithm decreases drastically when less sensor information is
available. In addition, this algorithm requires more memory allocated for the storage of
maze information, because it relies on two arrays to store horizontal and vertical walls.
This algorithm solves all mazes in software and has also been implemented to run on
the mouse, however a few glitches exist. Because Interactive C does not accept arrays
Fucsko, Houle, Mitro, Olson 12
with more than 16 columns, the dimensions of one of the maze wall arrays had to be
inverted. All the indexes in the code were inverted. However, this caused other problems
that we have not yet been able to identify. The mouse is able to solve simple mazes using
this algorithm. Nonetheless, it often returns an array out of bounds runtime error.
Fucsko, Houle, Mitro, Olson 13
APPENDIX C: Sensor Measurements
GP2D12 Calibration Curve
2.5
2
Vout (V)
1.5
1
0.5
0
0
10
20
30
40
50
60
70
80
90
Distance (cm)
Figure 13: Sensor Calibration Curve
Sharp GP2D12 and Microcontoller Interface
130
120
110
100
microcontroller output
90
80
70
60
50
40
30
20
10
0
0
5
10
15
20
25
30
35
40
45
50
55
60
65
70
distance (cm)
Figure 14: Microcontroller & Sensor interface
75
80
85
90
95
Fucsko, Houle, Mitro, Olson 14
APPENDIX D: Chassis and Sensor Diagrams
Bottom View
1.8
11
Ball Caster
8
4
Motors
Sensor
Wings
4
*All values in cm
Figure 15: Chassis and Sensor Layout
18
Fucsko, Houle, Mitro, Olson 15
Figure 16: Chassis schematic
Fucsko, Houle, Mitro, Olson 16
APPENDIX E: Hardware Analysis
Figure17: Intellimouse Fault Tree
Fucsko, Houle, Mitro, Olson 17
APPENDIX F: Intellimouse Budget
Table 1: Intellimouse Budget
Component
Estimated Amount
Actual Cost Difference
Microprocessor (Motorola 68HC11)
$350
$305.00
$45.00
Stepper Motors
$45
$43.64
$1.36
Sensors (Sharp GP2D12/GP2D02)
$60
$102.75
($42.75)
Mouse Chassis
$20
$2.55
$17.45
12 Pack NiMH Rechargeable Batteries
$35
$0.00
$35.00
Battery Charger
$20
$0.00
$20.00
Maze
$60
$170.31
($110.31)
Passive Components
$79
$0.00
$79.00
Active Components
$100
$0.00
$100.00
Printed Circuit Board
$200
$0.00
$200.00
Posters & Report Copies
$25
$47.40
($22.40)
Wheels & Ball Casters
$0
$25.00
($25.00)
Memory Latch
$0.45
$0.45
$0.00
32K SRAM Memory
$5.49
$5.49
$0.00
TOTAL
$1,000
$702.59
Remaining Budget
$297.35
Fucsko, Houle, Mitro, Olson 18
APPENDIX G: Test Results
Table 2: Intellimouse Test Results:
C. Measured Characteristic
Straight-Line Movement (w/out sensor feedback)
(1) Variation in distance traveled (%)
(2) Perpendicular offset (% of distance traveled)
(3) Velocity (m/sec)
Turning
(4) Variation in degrees turned (%)
(5) Angular Velocity (degrees/sec)
Micromouse in Maze
(6) Average number of steps before collision
(7) Average steps to solve maze
(8) Average time to solve maze (min)
(9) Maximum time to solve maze (min)
(10) Average time per cell (sec)
Micromouse in Software
(11) Average steps to solve maze
(12) Maximum steps to solve maze
(13) Average turns to solve maze
(14) Average time to solve maze (min)
(15) Mazes solved within time limit (%)
General
(16) Max Length (cm)
(17) Max Width ((including wings) (cm)
(18) Min Battery Life (min)
(19) Max Code Size (KB)**
D. Original
Specifications
E. Test Results
1
3
0.1
3.3
29
0.12
1
120
0.8
130
infinite
175
N/A*
10
N/A*
75
60
2.14
3.73
2.13
175
N/A*
N/A*
N/A*
100
133
578
129
4.9
81
25
25
15
16
14.5
24.5
> 60
10.3
Fucsko, Houle, Mitro, Olson 19
APPENDIX H: Test Plan
The following document can be used to verify that the Intellimouse Explorer
complies with the specifications listed in the table below.
Measured Characteristic
Straight-Line Movement
2.1 Variation in forward distance traveled
2.2 Perpendicular offset (% of distance traveled)
2.3 Velocity
Turning
3.1 Variation in degrees turned
3.2 Angular Velocity
Solving
4.1 Number of steps before collision
4.2 Average steps to solve maze
Original
Specifications
Guaranteed
Values
1%
3%
0.1m/s
< 5%
< 30%1
0.1m/s
1%
120(deg/s)
1%
> 120(deg/s)
infinite
175
varies
133
< 10 min3
4.3 Time to solve maze
General
5.1 Length
5.2 Width
< 10 min
5.3 Battery Life
5.4 Code Size
> 15 min
< 16 KB
1
2
3
4
< 25cm
< 25cm
2
< 15cm
< 25cm
4
60 min
< 16 KB
The perpendicular offset is corrected for during normal operation using feedback from the sensor wings.
The number of steps before collision varies widely. The mouse can run the maze one time and complete
it without crashing. On a second run however the mouse may collide with a wall a few steps into the
maze.
The maximum speed of the mouse limits its ability to complete some mazes within the 10 minute
specification. Using the speed values of the mouse we calculate that it can solve 80% of mazes within
the 10 minute limitation.
During testing we never fully tested the life of the battery. After one hour the test was ended because it
far exceeded the maximum amount of time allowed in the maze.
1. Preparation
In order to perform most of these tests, the mouse must be loaded with the test
software package included on the CD. Please refer to the user guide and follow the steps
in Section 2 to download test.c to the micromouse. For help navigating the test package’s
menu system, see Section 5 of the user guide.
Throughout this document references are made to sections in the User Guide. Before
beginning this test plan, either read and understand the user guide, or have it handy for
reference.
Fucsko, Houle, Mitro, Olson 20
1. Straight-Line Movement
2.1 Variation in forward distance traveled
1. Place the mouse somewhere with plenty of room to move forward. The mouse
will attempt to move 288cm forward.
2. Mark the mouse’s starting position.
3. Navigate the menu system on the mouse and select “Move Forward.”
4. Once the mouse completes its move, measure the distance traveled from the
starting position.
5. Calculate the percent error in forward motion using 288cm as the actual value.
2.2 Perpendicular offset
1. Place the mouse somewhere with plenty of room to move forward. The mouse
will attempt to move 288cm forward.
2. Run a long straight object parallel to the mouse touching the outside of its left
wheel. This will be used to measure the offset from. (The mouse pulls to the
right by default)
3. Mark the mouse’s starting position.
4. Instruct the mouse to “Move Forward.”
5. Once the mouse completes its move, measure both the distance traveled parallel
to the straight object from step 2, and the perpendicular distance from that object.
6. Divide the perpendicular distance by the parallel distance to determine the
perpendicular offset.
2.3 Velocity
1. Follow the steps in 2.1, but clock the time the mouse takes to complete the
process.
2. Divide the distance traveled by the time in seconds to complete the process.
3. Turning
3.1 Variation in degrees turned
1. Place the mouse on a piece of paper.
2. Mark the initial position of both wheels of the mouse on the paper. Somehow
differentiate the two wheels.
3. Instruct the mouse to “Turn Right.” (Be sure that the paper is held firmly in
place)
4. Once the mouse completes its turn, mark the new position of the wheels onto the
paper.
5. Measure the angle between the marks for each wheel. Calculate the percent error
using an actual value of 90°.
6. Take the average of both wheels to determine the variation in degrees turned.
3.2 Angular velocity
1. Place the mouse somewhere where it can turn in a complete circle.
2. Instruct the mouse to “Turn 360”
3. Divide 360° by the time taken to complete the maneuver.
Fucsko, Houle, Mitro, Olson 21
4. Solving
4.1 Number of steps before collision
The number of steps before collision is not a measurable specification. Repeated
testing does not result in a reliable result. The mouse either completes the maze
unhindered, or it crashes at some random point in the maze. Collisions are caused by
incorrect turn values. The incorrect turns are caused by the path correction algorithms. If
the mouse corrects its path just before turning it will not make a correct turn and runs the
risk of crashing before it can compensate.
4.2 Average steps to solve maze
There are two methods that the average steps to solve a maze can be calculated. The
mouse can be run in a multitude of mazes. The final step value displayed on the LCD at
completion can be recorded and an average of all runs on all mazes can be calculated.
The second method uses the random maze simulator. For help running the maze
simulator, see Section 4 of the user guide.
1. Launch the floodfill simulator.
2. Instruct the simulator to make multiple runs.
3. Specify the number of mazes to run. (The higher the number of mazes, the more
the result will converge to the true average)
4. When the simulator completes, divide the total number of steps by the number of
runs.
4.3 Time to solve maze
The best way to calculate the time to solve a maze is to time the mouse as it solves
the maze, but a way to calculate an approximate average for all mazes follows:
1. Calculate the Velocity as in 2.3.
2. Divide 16cm by the velocity in cm/s. (This is the time in seconds to move a step).
3. Calculate the average number of steps to solve a maze as in 4.2.
4. Multiply the number of steps from 3 by the seconds/step value from 2.
5. General
5.1 Length
The length of the mouse is the distance from the back to the front of the sensor wing.
5.2 Width
The width of the mouse is simply the width of the sensor wing (the widest part of the
mouse).
5.3 Battery Life
1. Place the mouse somewhere with plenty of room.
2. Instruct the mouse to “Test Battery.”
3. Time until the mouse stops working.
5.4 Code Size
Code size is shown when downloading code to the mouse from within Interactive
C. See Section 2 of the user guide for instructions to download code to the micromouse.
Fucsko, Houle, Mitro, Olson 22
APPENDIX H: Intellimouse Explorer User’s Guide:
1. Basic Operation
When powered on the mouse displays a menu on the LCD screen. Using the
control knob on the microcontroller the user can select from three options: testanalogs,
testdigitals, and floodfill. Once the option wanted is displayed on the screen press the
start button on the microcontroller to select it.
NOTE:If the mouse does not show this menu upon boot, download floodfill.c to
the mouse. (See Section 2)
1.1 Test Analogs – Shows the current value for the selected analog sensor.
• The control knob selects which sensor to display values for.
1.2 Test Digitals – Shows the current value for the selected digital sensor.
• The control knob selects which sensor to display values for.
• The display can also be set to display all connected digital sensors.
1.3 Floodfill – This setting instructs the mouse to solve a maze using floodfill.
• The mouse must be placed in a corner of the maze with its right side running
parallel to the outside wall of the maze.
• For optimal results the mouse must be centered in the starting square.
2. Downloading Code to the Mouse
2.1. First time
1. Install Interactive C. The latest version of Interactive C (5.0.0009) is included on
this CD in the Interactive C folder.
2. Connect the serial connector from the charging board to the back of the computer.
2.2. Downloading Code
1. Launch Interactive C.
2. Follow the connect steps for “Handyboard v1.2”
3. Open the C file to load to the mouse (floodfill.c or test.c) in Interactive C. (Both
files are located on the CD under the Code folder)
4. Press the Download button.
NOTE:If the mouse’s battery has died firmware will need to be downloaded to the
mouse first. This process is explained during the instructions for step 2.
Fucsko, Houle, Mitro, Olson 23
3. Modifying the Code:
Comments exist throughout the code to explain what different variables and processes
actually do. Some items of particular interest are:
• iGoalX & iGoalY – These tell the mouse where the goal is. Changing these
values will move the goal to the specified X, Y position.
NOTE:Coordinates in the mouse’s memory are tracked starting from the upper
left corner with (0, 0), X increases to the right, Y increases down.
•
•
•
•
•
•
•
iMaxX & iMaxY – The limits to the maze, helpful for testing on smaller mazes.
QuadrantI-IV – Biasing for different corners of the maze. Each define consists of
four two bit numbers combined. The numbers indicate the priority to choose
directions in case of a tie. Two older biases are commented out in the code.
Uncomment them and comment out the current ones to try them out. (Quadrants
are based on normal math quadrants, I is upper left, II upper right, etc)
iMaxDepth – Maximum recursion depth for flooding. This limits the recursion to
prevent memory overflow. Increasing the value allows the mouse to flood deeper
dead ends but increases the risk of memory crashes.
A hard coded 7x7 maze is commented out in the InitStart function. This maze can
be used for debugging the actual mouse code in Interactive C. If you uncomment
it, be sure to change iMaxX & iMaxY to 7.
Under the LookAround function there is a commented out section of code that
floods the entire maze every step. This will decrease the average number of steps
to the goal, but drastically increases thought time, try it out.
MMMotors.c contains all of the code to actually drive the motors. Large changes
will be required to this file if different motors are used.
test.c contains simple test functions for implementation of the testplan.
4. Simulators:
Included on this CD are two simulators for testing the mouse’s code on random or
loaded mazes. One simulator uses the floodfill algorithm implemented into the final
mouse, the other uses a logic based solving algorithm we were playing with through
development. Source code for both of the simulators is included along with some
example mazes.
4.1 Operating the Simulators:
Both simulators are operated the same way. Once one of the simulators is
launched it displays the following:
'l' to load a maze, else randomly generate one:
Enter l then pressing enter allows you to specify a filename for a maze to load. Some
example maze are included on the CD, they are the txt files in the Simulators folded. A
hidden command actually exists from this menu. If you type “m” (without the quotes)
press enter, then type “m” and press enter again it will ask you to specify a number of
runs. Enter an integer and the simulator will run on that many randomly generated
mazes.
Fucsko, Houle, Mitro, Olson 24
Once a maze has been loaded or generated you can step through the maze by
pressing the enter key. The floodfill simulator shows both the maze the mouse has seen
(with flood values in the squares) and the actual maze (with the path shown as the latest
step value at that square). The logic solver only shows the actual maze with the path.
Another hidden command exists immediately after generating a random maze. If you
type “s” then press enter the maze will immediately solve to completion.
NOTE:The simulators have nothing to stop them from terminating once the
program completes. Therefore it is recommended to launch them from a
command prompt so that the user can see the final results without the
window closing.
5. Testing
The micromouse can alternatively be loaded with a package of test routines. The
test functions use the same functions to drive the mouse as floodfill.c except that the
sensors are disabled. This section describes what each function in test.c does and how to
operate them. When powered on with test.c the mouse displays a menu system similar to
Section 1. The control knob on the microcontroller selects the test to perform. Once the
option wanted is displayed on the screen press the start button on the microcontroller to
begin the test.
NOTE:All of the test functions have a half second delay before they begin allowing
time for the user to remove their hand from the start button.
5.1 Move Forward – The mouse moves forward 16 steps (288cm).
• Adequate space should be provided in front of the mouse so that it does not crash.
• Space should also be left to the right of the mouse. By default the mouse swings
to the right by as much as 33% of its forward motion.
5.2 Turn Right – The mouse turns 90° to the right.
• Adequate space should be provided for the sensor wing to swing to the right.
5.3 Turn 360 – The mouse will make a 360° to the right.
• Adequate space should be provided for the sensor wing to swing in a complete
circle.
5.4 Test Battery – The mouse will move in a box to the right indefinitely.
• Adequate space should be provided for the mouse to move in a box.
NOTE:Over time errors will build up in the mouse’s turning. Space should be
provided to allow for these errors.