SDD Report

Smirnoff

ANDRZEJ KOWALCZYK – Microsystems Manager

ANDREJS GROSMANIS – Joint Software Manager

SAKARIYA KISOW – Mechatronics Manager

OLEGS MISSE – Joint Software Manager

Muhammad Waqas Ali – Project Manager

1
Abstract
The aim of our project was to design and implement a robot mouse that could take
part in a competition to navigate itself through a 9*9 square 2D random maze (smaller
than the maze implemented by the IEE’s micro mouse regulations) the maze squares
have sides of length 16.5cm. The specification stated that the mouse which found the
quickest route to the centre was the winner of the competition. For our group to
achieve this we had to pay great attention to chassis design, spatial awareness,
steering error correction as well as motion control.

Our intentions in writing this report are to provide an overview of the work carried out
in our second year micro-mouse project. There were five people in our team and we
divided the work according to our particular interests and abilities. This complex task
required excellent teamwork and communications.

2
Table of Contents
Page
Introduction 4

Time Plan 5

Mechanics 6
 Chassis 6
 Motors 6
 Batteries 8

Hardware Testing 9

Electrics 11
 MCU 11
 Interface with PIC 11
 Sensors 11

Sensors Testing 16

Software 17
 Motor Driver Routine 18
 Left turn 19
 Right Turn and U-Turn 22
 Steering correction 23
 Acceleration and Deceleration 24
 Sensor filtering 25
 Decision Routine 26

Conclusion 27

Appendix A – Schematics of Mouse 28

Appendix B – Power supply Schematic 28

Appendix C – Motor Driver 29

3
Introduction
The purpose of this project was to develop a greater understanding of electronic
circuits and programming with an example of its application and implementation. It has
provided us experience of designing through real application, simulating, prototyping
and in-laboratory testing of a real circuit.

During the designing phase of our project we worked tightly as a group, putting in our
suggestions so that the best solutions could be devised to create a mouse that was
fast, functional, and simple and that followed the guidelines given in the specification.

We used the wheel chair configuration for our chassis, because the chassis is the core
of our mouse and everything is built around it, therefore we had to make sure it was
strong and reliable and after reading a few case studies this seemed the best solution.
When we chose which sensors to use we veered away from the specification given by
our lecturer and made our mouse unique by instead of using reflection or beam
breaking sensors that we would instead use ranging sensors. These kinds of sensors
give a voltage according to the distance of the mouse to any given wall. We would
then not need to have wings to support the sensors and the mouse would be more
robust and have a smaller parameter. Due to the fact that the mouse uses ranging
sensors we had to use a PIC that had ADC’s on board to make the PIC compatible
with the sensors.

This report illustrates the thought process and development of our project over the
past few months. To achieve our objective in writing a thorough report it has been
necessary to break down the workload into three main sections; mechanics, electrics
and software. Each section has been broken down into subsections (as seen in the
table of contents) which give a more detailed analysis of how our project has been put
together. Although some parts seem more important than others, they all contribute to
the workings of a winning mouse.

4
Time Plan
Once the group had been formed we met on a regular basis to discuss the structure
and progression of our project. We found it necessary to meet regularly at the
beginning of the semester in order to plan our strategy and how to proceed. As the
members of the group became more confident within their roles our meetings became
less frequent. Below is a table which illustrates when our meetings took place and the
topics that were discussed during these meetings.

Date Topics Solutions

18th  Configuration of Chassis Wheelchair with no wings.
Jan  Size of maze Length of one square = 16.5cm.
 Sensors Distance measuring sensor.
20th  Choice of PIC Dependant on hardware and programmer supported
Jan by Uni. 32k of Ram needed.
 Model of sensors Sharp GP2D120. Range- 4cm to 30cm.
 Material for the wheels As light as possible.
 C compiler for the pic CCS
23rd  Choice of PIC Surfing the net to find PIC
Jan  Design of chassis Using measured size of maze, mouse needs to be as
compact as possible.

24th  Chassis Building and construction using aluminium frame with

Jan rubber on the wheels to prevent slipping.
25th  Testing of motor Manual testing by connecting to a signal generator to
Jan produce a pulse. Testing with a PIC 16f627 to
determine the best frequency, 500hz was best to
drive this pic. If freq is increased it works faster but
has to have a manual push and if it bangs into a wall
it stops needing an extra push. Therefore not
possible! If the freq was decreased then it started to
vibrate when moving. When trying to drive this motor
we first did high to low transitions which didn’t work so
we then drove it with low to high which worked
PIC 16f876 flash re-programmable
 Decision of PIC
1st  Size of maze 9*9 square maze
Feb  Algorithms Using the web and books in library
 Batteries AAA rechargeable batteries

8th  Attaching of Sensors week we established that the mouse was unable to
March power all the sensors the addition of the sensors
current is about the same as needed by the motors. A
solution was thought of that it would be possible to
control the power for each sensor from the PIC by
switching it on and off via a transistor, one for each
sensor. This solution will also solve the problem of
interference between the sensors.

During the spaces within the slots above we met to do the calculations for the mouse
and also to do tunnel runs to test the mouse and how it moves using a remote control.

5
We completed the hardware for the project by mid-April and the software was
completed at the beginning of May In time for the presentation.

6
Mechanics
Chassis:

The aim of the chassis design was quite straightforward, the chassis was made
as small as possible, to avoid any trouble whilst moving around the maze. To test the
chassis we wrote small program which moved the mouse along the maze. It
successfully runs, turns and rotates along the maze. The dimensions of the mouse
allow it to move about two or three squares without steering (Figure1). Therefore,
continuous steering is not required; it can travel for one square, then stop and check if
steering is necessary. For that reason, a lot of power can be saved by not powering
the sensors all the time, but only when needed. All four sensors draw about 250mAh,
which is a lot. For comparison, motors draw about 320mAh.

Figure1, Dimensions of Smirnoff

Motors:

We will be using stepper motors as these were supplied by the university. Also
it makes it easy to measure the distance travelled by counting the steps.

Motor calculations:
Frequency = 500 Hz (absolute max.)

t per pulse = 2ms

The wheel turns 1.8 degrees per pulse therefore it takes 200 pulses to turn 360
degrees.

t per turn = 200 * 2m

7
 = 0.4s

In order to calculate the distance covered by the mouse in one complete turn of the
wheels we calculated the circumference of the wheel

C = 2*r*pi
= 8*pi
= 0.25m

Once we had the distance covered and the time to travel this distance we could work
out the velocity

V = S / 0.4
= 0.625 m/s

Using an equation for the distance covered we re-arranged it to calculate the

acceleration. Although this acceleration seems extremely large this is just an
estimation and the mouse will not accelerate this quickly in reality because there are
factors which will slow it down such as weight and friction.

S = ut + ½at^2
= ½at^2
0.25 = ½a(0.4)^2

a = 0.25 / 0.08
= 3.125 m/s2

With the above info and the weight of our mouse we could calculate the force upon the
mouse

mass = 0.8kg (approx)

F = mass * a
= 0.8 *3.125
= 2.5N

The Torque for each wheel can now be calculated below using the radius of the wheel

T=F*r
= 2.5 * 0.04
= 0.1Nm

The angular velocity is:

W = peripheral velocity / r
= 0.625 / 0.04
= 15.625 rad/s

The input power is based on two motors. One motor requires 12v and a current of
160mA. For 2 motors we have the same voltage but the current increases by double.

Pin = V * I
= 12v * 320mA
= 3.84W

Pout = ( T / 2 ) * (W / 2 )

8
 = ( 0.1 / 2) * (15.625 / 2 )
= 0.39 * 2
= 0.78W

Using the above information we can work out the power efficiency for Smirnoff

n = 0.78 / 3.84
= 20.3 %

All the calculations are done for the extreme case, in reality it will be twice as light, and
slower by half.

The total power consumption for the motors and the motor drivers are:

Motors: 2*160 mA=320mA

Motor driver: 2*UCN5804 5V 30 mA (max.)=60mA

Batteries:

To get the best results out of our mouse we had to find some batteries that
were light, compact and supply at least 1000mA/h at 12V. This is because the mouse
uses around 500mA when it is in motion. This is a very high current, due to the
sensors that our mouse uses which is 200mA for all four sensors. When choosing the
batteries we are looking at the worst case scenario so that we could provide the
needed power.

The best solution was a combination of ten 1.2V AAA type battery of high capacity
which would produce a current of 1450mA. All the cells are connected in series and
will be attached to the inside of the chassis.

Assuming that mouse would use about 500-600mA constantly throughout the maze
the mouse should run for almost two hours which is much more than we need. 

9
Hardware Testing
Once the mouse had been fully designed, the schematics were complete and
the whole group was happy with the choice of the various parts of the mouse such as
the sensors and chassis design, the schematics for the motor driver were then
implemented on bread board. This allowed us to test to make sure that the circuits
were functioning as desired, once we observed that the circuit was correct it was then
designed and built on PCB.

To test the mouse with the motors and the motor board and to test whether it ran
smoothly, a control circuit was designed. This control circuit was configured using a
pulse generator chip NE5555 which sends a pulse to the motor driver chips making
the motors drive in a certain direction. The direction of the mouse can be controlled by
two switches which are situated one side of the control board (see figure 2). A variable
resistor situated next to the switches was used to control the speed of the pulses
therefore controlling the speed of the motors. The board is also supplied with 5v to
power the circuit.
Motor Driver

Control Circuit

Figure 2, Photograph of Control Circuit and Motor Driver

Once having successfully built the control board and connected it to the motor driver it
was possible to control the speed and the direction of the mouse therefore this test
proved that the motor driver was working perfectly.

Once the motor driver was built successfully the main PCB for the mouse was built.
This was the main board for the mouse which had all the vital components attached to
it such as the sensors, PIC and power supply. Once the board had been implemented
we tested it by plugging in the pulse and direction pins from the motor driver into the
relevant sockets of the pic holder, i.e. mimicking what the pic would be doing and
applied the power supply. Then using the control circuit we could test if the board
worked, this seemed very successful and the mouse moved as expected.

Once the main PCB had been successfully tested the sensors were connected to the
mouse and wired to the PCB, further testing took place to make sure the sensors
worked, instantly once the pic was turned on we realised that it was not possible to
have all four sensors on at one given time this was because they drained too much
power. This meant that the main PCB would have to be re-designed so that the

10
sensors could be powered by the PIC one at a time and the sensors would alternate at
a speed which would have the same effect as if they were all on at the same time.
This problem was solved by designing a new board in which the PIC had control over
which sensor was on at any given time. Once this new board was built we wired it up
again and were instantly confronted with a different problem. The sensors were still
absorbing too much power and this was leading to the step down voltage chip to
overheat. Once again a new board had to be built.

We observed that the new board had to control the power for the sensors through the
PIC but this time the power for the sensors would be drawn through four transistors.
Once again a new board was built and once again we were faced with more problems.
This time the board was made to specification but the transistor configuration was the
wrong one. In place of the PNP transistor array (which was not available) a ULN 2003
was inserted which we found was not adequate for this project. Instead we had to
build a circuit with a scanning socket which could control all the sensors and
transistors directly from the PIC which eventually worked as planned.

Each time after a new board was designed and implemented we tested the motors by
plugging in the motor pulse and direction pins into the pic socket and controlling it with
the control circuit.

11
Electrics
MCU:

We have chosen the PIC16F876 because it has enough memory for relatively
complex tasks, such as Lee's algorithm, it also can be reprogrammed many times due
its FLASH memory. It also has 10bit A/D which is necessary for our analogue sensors.
And most important, it is supported by our programmer board.

The PIC has 368 bytes of RAM which is enough for solving the 9x9 square maze,
which requires 256 bytes of memory therefore 128 bytes are left for other purposes.
The maximum program size is about 2000 lines of assembler code, which can be
fitted easily into available 8000 lines program memory.

The concept of the left-hand algorithm is rather simple; one loop with few conditional
statements, perhaps an averaging filter will be implemented to make readings from
sensors more accurate. Memory requirements for such program will be negligible. The
usage of ROM for look-up tables is not necessary, since all the decisions will be based
on comparing the values from the sensors. The estimated size of this program is
about 1000 lines, in the assembler.

The total power consumption for the microcontroller is:-

1*PIC16F876 5V 25mA (max.)=25mA

Interface with PIC:

Four sensors are connected to PORTA, since only this port has analogue input,
the sensor power (on/off) is controlled via PORTB, it takes one pin per sensor,
altogether eight pins, four analogue pins from PORTA and four digital from PORTB.
The motors are controlled via PORTB, two pins per motor will be required, one for the
direction and one for the pulsing. For two motors four pins are used from PORTB.
Total number of pins used is twelve the other ten pins are redundant.

Sensors:

Our mouse is using SHARP 2D120X ranging sensors; they give a voltage
according to the distance to the object with a 4-20cm range. At least two ranging
sensors will be required; we used four in our initial design just to make sure that it
definitely worked. We believe that four sensors will allow us to detect any combination
of walls, and the mouse will be able to make any decisions beforehand. The sensors
are controlled by the MCU, seeing as they all emit IR light at the same frequency it
can cause interference among them and will lead to false readings. To avoid that, they
will be switched on/off one by one in round-robin fashion this will also save a lot of
power and draw quarter the amount of current. The sensor mounting is displayed in
Figure 3 and 4. The sensors are attached to the chassis and pressed by two springs
what will stop them moving and allow us to adjust them to the exact angle.

12
The total power consumption for the four GP2D120 SHARP sensors is 5V*50mA
(max.)=200mA.

Motors

Spring

Sensors

Wheels

Figure3, Sensor Mounting (Front/Rear)

Sensors

Figure4, Sensor Mounting (Front/Rear)

Below is the sensor operation diagram which illustrates one of the possible sensor
configurations that could occur as the mouse navigates itself around the maze (Figure
5) if four sensors are used. The front of the mouse has the same configurations as the
back of the mouse therefore we are just illustrating one side of the mouse.

13
Figure5, Possible Sensor Operation Diagram

14
Use of One Sensor

During the design and testing of the software and sensor testing we came across the
idea that it would be possible to use only one sensor at a 45 degree angle to navigate
the mouse around the maze. In concept this meant that the mouse would be like a
blind man using his left arm (right front sensor pointing at the left wall) to guide himself
around the maze. If the mouse encountered the situation where there was no left wall
then it would turn left (see Figure6 bellow).
Mouse

Sensor
Maze wall

Figure6, One Sensor Configuration

Through testing we realised that this was possible and if the mouse came to a dead
end the two walls at right angle in front of the mouse (left wall and front wall) seemed
to the sensor as though it was a bending wall and the mouse steered right until it
encountered a straight wall again. If it came to a complete dead end the mouse would
do a u-turn and then carry on with its navigation.

Testing One Sensor Solution

Once completing the tunnel run successfully with the one sensor solution, the next
step was to try to introduce a turn around a bend. Once testing the mouse in the
condition with a left turn we encountered a problem which was when the mouse
crosses a wide range of space. When the mouse has a too big a gap it has no wall to
lead it therefore making it confused and it goes into an unexpected state which makes
it freeze.

A possible solution would be to drive the mouse blind for a certain amount of
interrupts. This means that we would de-activate the sensors for a short amount of
time and drive the mouse forwards, and then when the sensors were re-activated the
mouse would be nearer a wall and be able to follow it. After considering this solution
we thought that it wouldn’t be a good Idea to drive the mouse blind because this would
accumulate too many errors and eventually lead to the mouse’s software crashing.

Use of two Sensors

A new and better solution was conjured up by the software engineers to introduce a
second sensor at the rear of the mouse (see figure7, the diagonal lines represent the
vision and angle of the sensors). This would now mean that there would be two
conditions that had to be met before the mouse took a left turn.

15
 Figure7, Angle and Direction of Sensors in two Sensor Configuration

The first condition would be the front sensor reading that there was no left wall, once
this was read the mouse would then carry on forwards at a constant speed until the
rear sensor read that there was no left wall. Once this occurred the mouse would then
turn left for a timed number of steps until both sensors could read a left wall.

Testing of two sensor solution

Once completing the software for the two sensor configuration and testing it on the
maze we decided that this would be the best solution for our mouse. This meant that
that mouse would not need to turn blind for any amount of time during the left turn.
See the software section for the exact process that the mouse goes through to make a
left turn.

The main reasoning for using this configuration was that not only does it prevent the
mouse from crashing whilst it takes blind turns but it also uses half the power than the
first solution that was devised which incorporated four sensors.

16
Sensors Testing
Our group were advantaged by purchasing ready made sensors, although this
increased the budget quite excessively compared to the budget if using the Is471F
modulated IR detectors supplied by the university, this also decreased the amount of
problems that could have been encountered during the development and testing
phases.

Given that we are using range sensors instead of IR detectors we had to go through a
different process when programming our software to understand how the different
distances were represented. The initial step was to attach the sensors to an
oscilloscope and measure the possible ranges of distance in voltage. It was interesting
to see that as we moved the sensors nearer an object the voltage level increased and
then shot down as the distance range got greater again. The voltage range for the
sensors measured to have a minimum of 0.4v which represented the furthest distance
in the range which was up to 40cm and a maximum voltage of 3v which represented
4cm. As an object got hearer than 4cm to the mouse it became out of the range and
was not read, therefore giving an irregular reading.

Figure8, Analogue output voltage Vs Distance to reflective object

Once we had voltage measurements for the sensors we were able to design the
software so that when we were faced with all the different possibilities of sensor
readings the mouse would respond in the desired manner. When the sensors read a
distance the voltage would go through the ADC and the PIC would convert the
readings into values from 1 to 255. The software was designed so that there were
certain decisions within this range i.e. if it reads less than 64 it does something but if it
reads more than 128 it does something different. During the testing for the software on
the sensors we tried to change the ranges i.e. what it was doing by reading less than
64 it was now doing until 80. We changed these values until we felt that the mouse
ran smoothly and turned at the right time e.g. before it drove into the wall. Because the
range of the sensor was only 2.6v and there was a difference of 10.2mv between each
reading it was by trial and error that we chose the ranges for the mouse to have
certain conditions.

17
Software
For the sake of simplicity and reliability the software was written in C and all the
debugging was done with a client program for the PC especially written for this project.
The reason for this was to speed up the overall process of program development and
would also allow us to finish the project in the given time frame. Bellow in Figure 9
there is a behaviour flowchart for the micromouse. It is only a simple version which
gives an explanation behind the logic of our software.
In the first stage a small server program was written for the PIC which accepts
commands for the mouse from the client program written for the PC. The client
program could control all the movements and read mouse’s sensors. We could then
debug the algorithm on the PC without repetitively reprogramming the PIC. All
communications with the PC are done via the RS232 port at 115,200kbps. The
second stage was to transport the algorithm from the PC to the PIC, which took 5min.

Figure9, Behavioural Micromouse Flowchart

There are four main tasks that the mouse goes through that work simultaneously.
There is a dedicated task to read the samples and filter them. The software is in the
decision loop when the mouse has no other tasks to perform. By the time all three
interrupts are handled, the program returns to the decision loop where it takes all the
samples and performs median filtering on them i.e. decides which sample is correct,
then it makes a decision what action to take.

Figure9, Software Overview

18
Motor driving routines:

For each motor there is a dedicated interrupt, both interrupts occur every
16MHz/32, every two microseconds. Although it is too fast to drive the motors directly
at these frequencies, every interrupt routine has its own prescaler so that we can
choose the speeds of the motors very precisely using ratios like 2/3 11/20, 22/36 up to
1/255. Any combinations for both motors can be used from 0-255. This allows smooth
acceleration and seamless steering. It is especially important at higher speeds, where
any sharp motion discontinuities and causes trouble. Also the movement must be
smooth otherwise it will start shaking and will go nowhere. Below are the motor driver
routines:-

Figure10, First Motor Driver Routine

Figure11, Second Motor Driver Routine

19
Left turn:

The left turn was one of the most difficult parts of the project. The design of the
mouse was based on tracking the left wall. The position of the sensors, steering and
left hand side algorithm - all depended on the presence of the left wall. Because of the
absence of the left wall during the left turn we had to include blind turning into the
movement of the mouse. One of the problems with blind movement was that it created
unstable positioning of the mouse once it had finished the blind turn. The initial
position (before the mouse detected left turn) was important because immediately
after that the mouse started to perform its blind movement, during which it was not
able to correct any errors caused by the incorrect positioning of the mouse. Because
of this complexity the initial design which had only one sensor was changed to two-
sensor model. The second (rear) sensor allowed to us to control the mouse more
stably by decreasing blind movements to the absolute minimum. The second sensor
was not used all the time, only when the first sensor couldn't detect the wall. The
Figure bellow illustrates the process of a left turn using two sensors.

Front sensor

Direction

Rear sensor

Figure12, Left Turn Using Two Sensors

Only when the mouse is in the position where neither of the sensors can detect the
wall blind movements are used. Figure13 illustrates a 90 degree blind left turn.

Front sensor
Front sensor

Direction
Rear sensor
Rear sensor

Direction

1. 2.

Figure13, Left Turn Using Blind movement

20
Below is the flowchart which illustrates all the different possibilities for a left turn.

Left turn
Steering off

Switch reading ADC

from front to the back sensor

Keep
going

Yes
Is
ADC>center-10

No

Switch reading ADC

from back to the front sensor

Memorize current position & direction

Set rotation to the left

Left rotation blindly 200 steps

Stop motors

Set straight direction

for both motors

Start motors

Switch reading ADC

from front to the back sensor

Go blindly forward 150 steps

21
 Keep
Read ADC
going

Yes
Is
ADC<left

No

Go blindly forward 100 steps

No Is Yes
ADC<center

Stop motors

Switch reading ADC

from back to the front sensor Memorize current position & direction

Switch reading ADC

from back to the front sensor

Set rotation to the left

Start motors

Left rotation blindly 100 steps

22
 Keep
Read ADC
going

Yes
Is
ADC<center

No

Stop motors

Set straight direction

for both motors

Start motors

Figure14, Flowchart for Left Turn

U-Turn and Right Turn:

When the sensor detects the specific value for a dead end it does a blind turn 90
degrees to the right. Once it does this it reads for the wall again if it detects the wall
again it repeats this process until the value of the sensor doesn’t signify a dead end.
This way both actions; U-turn and right turn are implemented in one routine in this
case a u-turn is just two right turns.

23
Figure15, Right Turn

24
Steering Correction:

When writing the software for the completion of the maze the software manager
created a very clever piece of software which meant that in wasn’t necessary to
include a separate subroutine for error correction. Instead the software was written so
that there were only two conditions; driving forwards or turning. If the mouse was in
motion and the sensor read that it was too near the side wall the software would think
that it was in the same condition as when it came to a dead end and had a wall in
front, therefore the mouse would turn until the wall was a certain distance away from
the sensor and then carry on in a straight line. This was very convenient as the
software became much simpler and meant that it used less of the PIC’s memory.

Figure16, Flowchart for Left Steering Figure17, Flowchart for Right Steering

25
Acceleration/Deceleration:

There was a problem during the acceleration movements whilst the mouse went blind
for the 20ms and 5ms (see flowcharts bellow). During these time periods it was
possible that the delays could overlap with a very important part of the programme
therefore leading the mouse to crash. During the testing we found that the mouse
functioned better without the acceleration and deceleration procedure. Therefore
these two movements were not included into the programme as they weren’t an
integral part of the mouse.

Initially this was done by incrementing/decrementing the motor speed prescaler

variables by the same value for both motors. Below are the two flowcharts that
illustrate the process of acceleration and the deceleration if they had been used.

Figure18, Flowchart for Acceleration Subroutine

Figure19, Flowchart for Deceleration Subroutine

26
Sensor filtering:

The use of a median filter was necessary as without it the mouse often read extremely
wrong results, this was due to the sensor taking measurements every 10ms, and in
the situation where we took samples at every 15ms errors were even more likely to
occur. At the beginning we tried to avoid this problem by using 3 point averager but
the error produced by the averager was not acceptable. For example if the first two
measurements were 100 and 100 and the third was 30 then the average value would
be 77, when actually the real value was 100. We could tell by these results that the
third sample was clearly an error. The consequences from these errors could have
been dramatic, such as the mouse bumping into the wall and then becoming stuck
forever, unless a recovery routine was implemented.

Figure20, Sensor Reading and Filtering Task (3 point median filtering)

With this task the mouse reads the sensors and takes three sample puts them through
a median filter and stores the result in a global variable which the other routines can
access.

27
Decision Routine:

The decision task runs during the spare time, between two interrupts therefore making
this task a lowest priority. It decides where to accelerate/decelerate, steer and turn left
or right. The sensor filtering is also done here along with maze centre detection. Below
is a flowchart that illustrates the decision routine.

Figure21, Flowchart for Decision Subroutine

28
Finding the Centre of the Maze:

When mouse performs any action it memorizes it, this is needed for making a decision
whether it is on a vertical or horizontal axis and whether it is going forward or
backward on the current axis. We call the vertical axis X and the horizontal Y. The
distance from the centre of one square to another is approximately 500 steps,
therefore on a 9x9 square maze the centre is between 1700 and 2300 steps on the X
or Y coordinate. When values of X and Y are within this range, it means stop. It might
be not exactly the centre where the mouse will stop, but this is the maximum possible
approximation, most of the time it will stop exactly in centre. The approximation is
necessary due to steering, skidding or other possible errors. There are no exact
values for X and Y coordinates.

Center

2000
steps

500 Y
steps
2000
steps
Figure22, Coordinates of the Maze

On the next page there is a behavioural chart for the mouse when it is in navigation
which determines the direction and on which axis the mouse is moving.

29
 No
Are we going
straight ?

Yes

Are we on Are we going

vertical axis ? forward ?
No

No
Yes Yes

Increment Decrement
horizontal step horizontal step
Are we going counter counter
forward ?

No

Yes

Increment Decrement
vertical step vertical step
counter counter

Return

Figure23, Navigation Behaviour chart

30
Conclusion
Our group were very motivated to complete the project in the time scheme issued by
the lecturer, we were extremely organised to the extent that the project was split into
relevant workloads and distributed to the relevant group member that felt most
capable of completing the task. One problem that was encountered by attacking the
project in this manner was that there was not enough communication between the
group members, and people were too keen to complete their tasks without speaking to
one another to confirm that the various sections were compatible with each other. This
lead to some of the PCB’s having to be built more than once and the software also
having to be re-written to be compatible with the hardware. This wouldn’t have been a
problem if the solution for each section was discussed in detail with each member of
the group.

One major problem we encountered during the project was that the power consumed
by the sensors was extreme. We established that we would be unable to power all the
sensors at once seeing as the addition of the current needed by the sensors was
about the same as the current needed by the motors. We solved this by controlling the
power for each sensor by the PIC. This was done by switching each sensor on and off
via four transistors, one for each sensor. Doing this meant that only one sensor would
be on at any one given time. This solution also solved the problem of interference
between the sensors.

Once of the main Issues that was brought up with the group members was that the
whole mouse could have been simplified dramatically therefore giving a much smaller,
less detailed mouse. Before the software was designed the software managers
thought that the software would be extremely complicated and difficult to debug
therefore they requested the mechanical managers to allow them to have the ability to
attach the PIC to the PC whilst it was in the PCB therefore needing a male-female
adapter and a S232CN chip and several capacitors. But once the hardware had been
built and the software was in the midst of designing the software managers realised
that they didn’t need to have the ability to attach the mouse to the PC even though it
was useful at times therefore the whole adapter circuit wasn’t vital. Also because only
two sensors were needed this could have simplified the PCB because we would not
have needed to use as many IO ports. Due to the fact that the software only used 25%
of the memory of the PIC we could have also used a different PIC with much less
memory space.

As a group we found this project quite tiring as it had many modifications and the
software kept evolving into something new therefore new problems arose and new
solutions had to be created. Although we had problems we managed to stay to the
specification and complete the project as desired.

31
Appendix A
Schematic of Micro mouse

Appendix B
Power Supply

32
Appendix c
Motor Driver

Motor2 Motor1

DRIVE BOARD

IC2 IC1

6 6
UCN5804 UCN5804

P2 D2 P1 D1 5V GND N.C. 12V

33