micromouse final report

Queron Williams Micromouse – Final Report 03/04/2012 10031755

1

Robotics Group Project 2011-2012

Final Report

Micromouse Queron Williams and Adam Waterman


2


Final Report – Contributions

This page shows the percentage contribution made by the group members (Queron

Williams & Adam Waterman) over the last year.

Sections Section

weightings

Contribution per section Total percentage

Queron Williams

Adam Waterman

Queron Williams

Adam Waterman

1st term presentation

12.5% 50% 50% 6.25% 6.25%

2nd term presentation

12.5% 100% 0% 12.5% 0%

Control report

25% 100% 0% 25% 0%

Final report 50% 100% 0% 50% 0%

Total

Queron Williams

Adam Waterman

93.75% 6.25%

I agree to the figures shown in the table above:

Queron Williams: . date: .

Adam Waterman: . date: .


3

Introduction:

This document is a report on the design, building and testing of an intelligent mobile robot that was

created to compete in a ‘Micromouse’ competition. The Micromouse robot was designed, built and

programmed by Adam Waterman and Queron Williams over the 2 terms of this academic year. In

this document will detail all the problems we faced during the design and construction of this robot,

It will also explain the solutions we came up with and our reasons for choosing particular solutions.

But what is Micromouse?

“Micromouse is an event where small robot mice solve a 16x16 maze. The maze is made up of a 16

by 16 grid of cells, each 180 mm square with walls 50 mm high. The mice are completely autonomous

robots that must find their way from a predetermined starting position to the central area of the maze

unaided. The mouse will need to keep track of where it is, discover walls as it explores, map out the

maze and detect when it has reached the goal. Once the optimal route has been found, the mouse

will run that route in the shortest possible time.”

Aims and objectives:

Design and build a small robotics platform that is capable of exploring within the size

constraints of a standard Micromouse maze.

Explore the use of DC motors with feedback in a precision control application.

Think about hardware design constraints for building a robot to perform a specific task.

Find sensors suitable for close range distance detection for use on the Micromouse.

Explore navigation strategies for mobile robots including the use of odometery and sensor

feedback

Design all of the Micromouse hardware including chassis parts and electrics systems for the

mouse.

http://en.wikipedia.org/wiki/Robot


4

Conceptual Design:

From the very beginning of this project we had a clear goal set out which we wanted to work

toward. We wanted to produce a very compact and professional looking mouse, making the design

as small as possible but without compromising the functionality of the mouse. We wanted to make

sure that the hardware design would never restrict the development and functionality of the

software.

Electronics design constraints:

We were provided with 2 geared DC motors that would be used for drive. They required 6V

to run and can pull up to 600mA of current under heavy load. This meant that our battery

would have to be above 6V to get full power from the motors.

As we were building a mobile robot all of the electronics would need to be as efficient as

possible and would need to be able to run from a small battery. This meant that all

components would need to be as efficient as possible as this would prolong battery life.

We had to choice of what microcontrollers to use but we would need something that was

fast enough to run PID and control loops for the motors as well as AtoD for reading the

sensors and UART for communication.

The goal was to make all of the electronics as small as possible so that the design of the

mouse did not have to change to accommodate the electronics.

Electronics design Decisions

We decided to use DSPIC microcontrollers from microchip as these provided features that

would be very useful whilst developing the mouse such as in circuit debugging. They also

include some specialist features that are not included in lower end PICs such as QEI modules

(Quadrature Encoder Interface). These allow hardware reading of the encoders inside DC

motors.

The mouse’s performance (acceleration and cornering) would depend a lot on the weight of

the mouse. We knew that we would need high power batteries to provide the current

needed by the motors. We looked at some small nickel metal hydride batteries however

found that the maximum discharge current was typically 200mA which was far too small. We

decided that we would have to use a LiPo battery for the mouse due to their high energy

density. We were able to find a small 2cell LiPo that runs at 7.4V and has a capacity of

600mAh (enough for at least half an hour of use at full power). Unlike the NiMh this battery

is capable of up to 12A discharge rate so is far more than the 1.2A needed by the mouse.

As we had no experience picking sensor’s we decided that we would do research and find a

few suitable sensors then run our own tests on these to find out which would be best for our

application.

We hoped that we would be able to have surface mount PCB’s produced for the final mouse

so made sure when choosing components that surface mount alternatives were available for

each component that we used.

To drive to motors we decided to use the LM293D dual H-bridge motor driver. We chose this

IC as it can drive 600mA per channel whilst being smaller than other alternatives on both DIP

and TQFN package.


5

Chassis design constraints:

Each cell of the Micromouse maze is

180mm x 180mm. the walls are typically

12mm thick leaving 168mm x 168mm

space inside each cell. The Micromouse

would have to be able to fit within this

space.

Whilst there is no height constraint for

Micromouse an increased height also

increases’ inertia during acceleration and

cornering. For this reason we decided to make the mouse as low as possible when designing.

To be able to map the maze we would need to be able to check for walls both in front of the

mouse and at both sides of the mouse.

Another big goal for our hardware design was that we wanted the hardware to be able to

travel diagonally in the maze. This was so that if we ever got the software to a point where it

was possible to implement these sorts of movements we would not be restricted by the

hardware.

Chassis design Decisions:

The width of a square is 168mm and as we wanted to be able to turn within one square. We

also wanted a space around the mouse at all times to account for any errors in the

odometery .we decided that limiting the diameter of the mouse to 14cm would allow us to

have 14mm around the mouse when in the centre of the square.

The width available if you wish to travel diagonally is 113mm. as we would like as much

spare space as possible to avoid clipping

wall corners we decided to try and limit

the width of the mouse to no more than

90mm, leaving about 13mm clearance on

either side.

The goal of the chassis design was to

make the mouse as small and compact as

possible without compromising on

functionality.


6

Work Program:

At the beginning of this project we decided to produce a gannt chart detailing when each part of the

project would be completed and who would do this. The gannt chart from the beginning of the year

is shown below.

The purple sections of this chart show the work that we planned to do together or share equally.

The blue section of the chart show Adams planned contribution towards the work.

The orange sections of the chart show my planned contribution towards the work.

To help split work up we decided to use 2 PICs on the Micromouse. One pic would deal with all the

motor control, PID and sensors which would free up a lot of cpu time on the other pick for running

flood fill simulations and making all the search decisions. This is kind of like a driver/passenger

situation where the driver is in control but is directed by the passenger.

We had decided that Adam would focus more on the ‘AI’. This included writing the flood fill and

decision making software for the mouse then porting this onto the ‘passenger’ pic.

I would then focus more on the ‘driver’ pic writing the lower level software that interfaced to the

hardware.


7

Unfortunately the work flow that we had agreed on did not work out as during the second term as

Adam decided to leave the course. This meant that I received no contribution from him during the

second term. This made the rest of the project much harder for me as it meant that I would have to

cover his sections of work as well as my own.

By the end of the second term I had managed to catch up with most of the extra work however due

to the lack of time I was unable to finish some sections of the mouse to the level of standards I had

hoped for at the beginning of the project.


8

Hardware and software design:

Laying the foundations:

From the outset of the project we knew that we

wanted to get some working hardware and a

prototype to begin testing with as soon as

possible. We were issued with a development

board and motor driver board for doing early

testing on. The development board comprised

of 2 DSPIC 30F4011 microcontrollers. All of the

I/O pins were easily accessible and the board

contained all of the power regulators needed to

run. It also contained a USB to UART module for

easy testing and debugging as well as

programming headers to connect to a PICKIT 3 programmer.

We spent the first few weeks writing functions that we knew we would need later on in the project.

This was completed using the provided development boards. This included things such as setting up

timers, Interrupts and general I/O. we also tried to get all of the modules that we would need

working. This included things such as the PWM needed for the motors, UART for communication and

ADC (Analogue to Digital Converter) that we would need for the sensors.

Once we received the motors we started working on making a set of motor commands that could be

used to set motor speeds and directions. We also setup the QEI modules so that The Encoders built

into the motors could be easily read and used for more accurate control.

We decided that to progress with the testing we needed a basic chassis to test motor control on.

This lead to the creation of prototype 1.


9

Prototype 1:

Prototype 1 was a basic chassis designed to

hold the motors, a small rechargeable battery

pack, the provided motor driver and the

development board. Its purpose was to allow

the development platform to become mobile

and test the motors under strain (which could

not be done with the motors sat on the table).

We did many tests on the motor control and

communication with this chassis. we sent QEI

values from one encoder over UART to the

other pic which would try and match the

position with the other motor. This was easy to get setup however we found that it was very

‘choppy’, the second motor was noticeably less responsive. This was due to the transition time,

which was limiting how often we could update the target position. The UART was set to 9600baud.

To send a start char, a 16bit integer, a stop char (used for error checking) and the start stop bits it

took 40 bits to send the message. We tried increasing the UART speed however found that even at

the fastest possible speed it was still slightly noticeable.

We realised that whilst sending just encoder data was fine, when we started sending encoder data,

sensor data and speed commands over the UART it would become to slow to give us reasonable

response. This caused us to rethink using the UART for communication. We looked into SPI, I2C and

other alternative communication protocol’s as well as alternate solutions to the problem.

Eventually we found that some of the DSPIC33f range was fitted with 2 QEI modules instead of the 1

found on the 30F4011. This would mean that we could control both motors and read both encoders

from the same PIC. This meant we would not have to send as much data between the PICs so the

UART became reasonable means of communication again.

We finally decided upon the DSPIC 33FJ128M802 as this had 2 QEI modules, ADC, UART, PWM and

everything else that we needed. We also chose a 28pin variant of the chip as it was far smaller than

the 44pin chip that was on the development board and we did not need all of the extra I/O pins.

One main difference with the 33F series is that it has re-mapable pins. Whilst being very useful for

tidying up circuit design and grouping certain pins it also caused some confusion to start with as we

had not encountered a PIC like this before. Once we had worked out how to assign and address pins

we got this working on breadboard along with our chosen motor driver. We found that we had to

modify some of our already written code to work on the 33F however this was relatively easy and

well worth it.

At this stage we were happy with the progress we were making on the software and electronics so

decided to shift some focus towards what we wanted the mouse to be like.


10

Prototype 2:

We started to mock up some size guidelines in Sketch Up (a free 3d design program) and started to

plan what we wanted the mouse to be like. We already knew our maximum size constraints so that

we had sufficient space to move around easily inside the maze. We modelled a work area with a

diameter of 14cm and width of 9cm inside a maze square so that we had a size reference to work

from.

We had learnt from the Lego wheels used I the

first prototype that smaller wheels made

movement a lot more accurate (even if reducing

top speed) and that the higher torque provided

by small wheel helped greatly in overcoming

turning moments. For this reason we decided to

buy some pololu R2Wi micro sumo wheels for our

final mouse. They are only 31mm diameter (only

just bigger then the 26mm motor) but provide

large amounts of grip so should allow us to

accelerate, beak and corner harder without losing

accuracy.

Next we modelled the provided motors and the

9V battery we would use in the prototype so that

we could build the design around them. We had

decided that rather than using motor mounts we

would use 2 layers of PCB bolted around the

motors to hold them in place. We decided that we

would have 2 main boards top and bottom then

have one smaller board with the sensors that fit in

the middle.

As we did not have pcb designs at this point we

decided to build a scale model to check out the

design. This was constructed from thin ply instead

of PCB so that we could check that the design

would work.

This chassis was a good size to fit inside the maze

and was able to hold either our breadboard and

motor driver or the development boards.

However it quickly became apparent that whilst

the wood that we had used was strong enough to

securely hold the motors, a PCB would not be as strong in the same situation. This caused us to

rethink the way I was going to secure the motors in the final mouse.


11

Prototype 3 design:

After testing with prototype 2 I decided that I was at the point where I could make a strip board of

the design and move away from using breadboard. The problem is that the current design would not

allow for this and placing enough force to hold the motors would break the strip board.

After considering many different ways of mounting the motors including milled or laser cut motor

mounts I decided to use 3D printed parts. This allowed for more flexibility in the design than using

laser cut parts however would still be far easier to produce than having parts milled by hand.

The design for prototype 2 focused around using our own electronics and having a large space at the

front to try out different sensor configurations and layouts. I also included a large battery ‘bucket’ so

that whilst testing the mouse could use any battery back rather than just the LiPo pack. The initial

designs were done in sketch up however these had to be redone in Solidworks so that they could be

exported to the right file type for the 3d printer.


12

PID:

Once the parts were sent for printing it would be a while before they were returned so I decided to

test our sensors and continue with the software.

The proportional motor control that I was currently using was not operating as I had hoped and was

giving me steady state error (it was not reaching the target as when close it did not have enough

power).I decided that the best solution to this would be to add PID control to the motors. PID

(Proportional Integral Derivative) control uses a constant feedback loop from the encoders to

control the motors. It basses its calculation on its distance from its target and the sum of past errors.

Each term is calculated as shown below; dt is the time between adjustments.

error = target - feedback

integral = integral + (error*dt)

derivative = (error - previous_error)/dt

output = (Kp*error) + (Ki*integral) + (Kd*derivative)

I found this easy to implement however tuning the values for Kp, Ki and Kd were more difficult as

this is something that I did not have experience with.

I decided that as I wanted to have very accurate control of the speed at which the mouse would

travel whilst performing movements I would use the PID to control velocity.

I run the PID routine from an interrupt triggered every 10ms. This meant that dt was always constant

and made calculation a lot easier.


13

Prototype 3 build:

2 small sensor modules were made with the chosen sensors to test different positions. These were

connected with Lego and could easily be reconfigured to try different angles.

Our idea for the sensors was to angle them by a

small number of degrees so that when the mouse

is straight in the maze sensor readings are not

being taken at surface normal. This means that if

the mouse begins to angle towards one wall it

approaches that walls surface normal and

reflection will be higher, meanwhile the other

sensor moves away from the surface normal so its

reading decreases.

Once the parts returned from the printers I built the strip boards and assembled prototype 3.


14

Movement commands:

Once the PID was implemented and I had working sensors it was time to start working on making the

mouse execute a list of movement commands allowing for navigation around a predefined route.

The commands worked by setting wheels to a target velocity and waiting until they reached their

target position. For straight sections and on the spot turns I could assign target speeds directly to the

wheels however for curved corners I had to work out the ratio between the distance travelled by the

centre of the mouse and the outside/inside wheels. This ratio was then applied to the wheel speeds

so that both the inside and outside wheel would reach their target position at the same time.

I found during testing that there were some inaccuracies in the PID. These were due to overshoot in

target because when the target was reached and velocity was set to 0 the PID took a while to react

and stop the motors.

This was fixed by putting the PID Velocity control inside a loop that adjusted the speed based on

integral error of the position. As the PID run at 10ms and the target speed is measured in QEI steps

per 10ms the time base for both is the same. As speed = distance over time and time is the same for

both units, the speed per 10ms is equal to the distance in encoder counts in 10ms. This means by

counting the error between target speed and actual speed you can count the error in position. This

was used to update the target speed and counteract any overshoot/undershoot when motors

changed speed.

When traveling in a straight line between 2 walls I was also able to use the reading from the sensors

to proportionally adjust the target speeds. This means that if the left reading was greater than the

right the mouse made the left wheel fast than the right. This has the effect of centring the mouse

between the walls as it travels.


15

Sensor positions:

Through testing with this version on the mouse I had worked out that for best results with the

sensors they needed to be offset by about 15*.

In the final mouse I wanted one sensor on each side of the mouse for centring whilst moving down

the straight sections and 2 on the front for aligning to a wall in front of the mouse. I worked out a

suitable sensor arrangement based on the angles I had deduced from testing.

In the setup shown above each sensor is exactly 60mm away from its wall when the mouse is in the

centre of a square. The diagram shows the sensors as the mouse is inside a cell, a quarter into the

next cell land half way between cells. When at the quarter position the mouse can already see if

there are walls in the next cell or not. This can be used to predict whether the mouse may need to

turn in the next cell before the wheels have entered the cell.


16

Final mouse design:

With the final mouse design I knew the size of the strip board and knew the position and angles of

the sensors. I also knew that this mouse would only run with the LiPo battery so knew exact size

requirements for all components. The design was made so that it was as compact as possible. I

mounted the motor the same way as before however secured the 2 pieces with 2 bolts instead of 1

so that I could tighten the top and bottom individually. The front and back section were lowered so

that the entire bottom could be used as a caster rather than having a single point of contact that

could get caught on bumps on a rough maze surface. The design also included a removable sensor

piece so that the sensors could be removed and worked with easy access for soldering.

In total I managed to reduce the new design to only 80mm width and 100mm length.

The main board from v3 was cut down to the new size and a few small alterations were made so that

it could fit the new form factor. I added the ability for the pic to turn the emitters on and off so that

we could perform better ambient light correction and added a surface mount status light to help

with debugging.


17

Mapping the maze:

As I could already run known routes through the maze the next challenge was to get the mouse

mapping the maze autonomously. The plan was for the muse to use flood fill to find the shortest

route through the maze however this required us to know that the mapping was working correctly.

The easiest way to solve this problem was to get the

mouse to “left wall follow” and create the map whilst

passing through each square. I found this very hard to

debug as we had decided to store all the information

about the map into a 3d array. The mouse could not be

run around a maze from the computer and using the in

circuit debugging meant that the mouse needed to be

connected to the computer in order to look at the data

in the array.

I overcame this problem by fitting a small Bluetooth

module to the mouse. As I had not yet added the

second pic to the current design I was able to use the

UART to send data back to the computer or a tablet

about the mouse’s position in the maze or about its

surroundings. This proved to be an incredibly useful

debugging tool but even so the data being received

was not easy to understand.

I decided to write a quick application that would run on

an android tablet that would use the data about the

maze sent back from the mouse to show the map that

was being constructed in the array. This easily allowed

me to fix problems in the way the data was being

stored and read from the array. it helped me overcome many of the problems of working on a

system with very little feedback as I could send debugging messages back from the mouse to the

tablet.

The tablet application

showed which cells had

been searched, where

walls had been found and

was also able to show

current flood fill data

(although I never got

around to sending this

type of data).


18

Testing and results:

Sensor testing:

When trying to find sensors to use on the Micromouse I

found that I had very little experience with this kind of

sensor. I decided that the best way to get a good sensor was

to make some researched /educated guesses as to which

sensors would be suitable then order a few different types

and test them against the Micromouse wall.

When choosing some sensors for testing I tried to get a wide

variety of different types including photo diodes,

phototransistors (2 and 3 pin) and some other IR range

finders with built in amplifiers.

These are the sensors that I ordered:

1. BPW77NB – 5mm, metal can phototransistor (3 pin)

2. BPW85 – 3mm, phototransistor (2pin)


4. SFH213FA – 5mm, photodiode (2pin)

5. SFH310FA – 3mm, phototransistor (2pin)

6. TSL262R – photodiode & transimpedance amplifier

(3 pin)

7. TSOP4P – photodetector & linear distance amplifier

(3pin)

The first task when I received all of the sensors was to make

up circuit diagrams for each sensor. When each schematic

was finished I made up one test board for each receiver. The

test board has a 3pin connector to provide power, ground

and receive the output from the sensor. Each board also

includes one of the SFH4550 high power IR emitter we have

chosen to use for the project and a current limiting resistor. I

chose this emitter because of the very tight half angle and

the high output power.

I found when breadboard testing to get the sensors working

that the TSOP4P was very accurate and linear however it had

a range that was highly unsuitable for our application (1-40

meters) so it was not carried on to extensive testing.


19

Test rig:

I decided the only way to accurately test all the sensors was to build a testing rig in which I could

accurately control both the distance the sensor were from the wall and the angle of incidence.

The rig was constructed with Lego and contained 2 stepper motors. One stepper was connected to a

linear actuator for controlling distance from the wall and the other was connected to a segment of

the maze so that it could adjust the angle of incidence. The steppers were controlled from an

arduino which was also responsible for taking readings from the sensors and sending them back to

the computer over usb.

A simple application for ‘Processing’ was written to accurately read in and display all the data

collected for each sensor. The graphs show how the sensors readings change with distance at the

surface normal and also with angle at set distances.


20

Results of Sensor Testing:

1. BPW77NB – 5mm, metal can

phototransistor (3 pin)

This was the most expensive sensor that I

brought however I was disappointed by the

performance. It was very non-linear as the

angle changed and also provided inaccurate

readings very close to the wall. I believe that

this was due to some reflection from the

metal case of this phototransistor


This sensor provided mostly linear reading

for angle and a good range of readings for

distance.


Results from this sensor were almost the

same as from its 3mm variant however I

noticed slightly less saturation at 2cm.


21

4. SFH213FA – 5mm, photodiode (2pin)

I found that this sensor suffered from large

amounts of noise and whilst this could be

solved by adding smoothing capacitors to the

output this would increase the ADC sample

time needed to get an accurate reading.

5. SFH310FA – 3mm, phototransistor (2pin)

This sensor also provided good results

however I found that it saturated easier that

some of the others I tested at ranges >3.5 cm

6. TSL262R – photodiode & transimpedance

amplifier (3 pin)

This was another sensor that I had high hopes

for due to the inbuilt amplifier and ambient

light removal however I was disappointed by

the level of output. I also found that due to

the large half angle it was not good at sensing

the angle of the wall.


22

I decided to go with the BPW96 – 5mm, phototransistor for use on the mouse as this provided both

a wide range of readings for distance and a linear angle profiles at most distances.


23

Wheel sizes:

On problem I started to encounter when I started working on the odometery

for the mouse was that I did not know the exact wheel diameter. Using 31mm

diameter as stated in the datasheet for the wheels was making the mouse fall

slightly short of its target distance each time it moves one square forwards.

Whilst this was only by a couple of mm per cell over a long straight of 10 cells

it would cause the Micromouse to completely miss a turn at the end. I tried to

measure the wheels with a set of venire callipers but the soft compound used

for the tyre made this difficult and the results were less accurate than before.

I realised that best way to get an accurate measurement was through an iterative testing process. I

would run the mouse for a known distance (say 1 meter) then measure the error in its final position.

This could then be factored in as a percentage and used to adjust the measurement of the diameter

in the code. This process was repeated a few times, each time making finer and finer adjustments

until the robot could reliably go the set distance correctly.

I also found that as I was using wide wheels they did not grip exactly in the centre as expected. This

meant that when I calculated the distances for turning movements the measured distance between

the wheels would cause the mouse to overshoot when cornering. I found the most accurate way to

fix this was again through repeated testing. This time I would have the mouse do 10 full rotations on

the spot and measure the error in angle of its resting position. This could then be factored back into

the width of the mouse in the code. This was repeated until the mouse was able to perform many

full rotations and still keep an accurate angle.

Together accurately testing these 2 measurements greatly improved the performance of the mouse.

It meant that it was having to correct its position far less often and was also more reliable when

moving through sections with many turns and fewer reference points.


24

Ambient light correction:

As I had purchased narrow wavelength emitters and receivers I had initially decided that we did not

need to filter the ambient light as the mouse would not be used in direct sunlight at any time. I

found this to be an incorrect assumption though as I found that during the day, every time the

mouse faced in one particular direction it was getting false readings from one set of sensors and

seeing walls that were not there. After some debugging I realised that this was due to ambient IR

light that was coming from a window near the maze. It became apparent that I needed to add some

form of ambient light removal to them mouse to solve this problem.

The easiest way to do this was to take one reading of the light level with the emitters off to calibrate

the ambient level then one reading with the emitters on. The ambient level could then be removed

from the 2nd reading to leave only the difference caused by the reflection of IR light from an object.

I found that due to the turn on time of the led these readings could not be taken straight after each

other. This was solved by setting up an interrupt that is triggered 100 times a second, each time it is

triggered I alternate whether the mouse takes an ambient reading or an active reading. This means a

large change in reading may only be recognised at 50Hz however this is a far higher refresh rate than

is needed by the mouse which travels typically at less than 1 cell per second.


25

Problems Encountered:

Work distribution:

Whilst work was distributed evenly through the first term this changed in the second term. One of

the group members left unexpectedly and this pushed a large workload onto just one person. This

meant that rather that splitting the tasks up between partners I had to complete all the tasks by

myself. I feel that despite this I was able to produce one of the highest quality micromice of any pair.

Sensor testing:

I did not begin sensor testing until a few weeks into the second term and whilst I was very pleased

with the results, not knowing which sensor I was using did hold up development of the hardware. I

think that if I was to redo this project I would have prioritized starting the sensor testing earlier on in

development. This would have meant that i could have chosen sensors and had them ordered by

then end of the first term. If I had the sensors at the beginning of the second term then I could have

pushed on with the chassis development earlier on and this would have left more time for finishing

and optimising software.

Time management:

Due to the increased workload I found that towards the end of the project I was very short on time.

As I need to leave enough time to finish off reports I did not have time to fully finish the mouse to

the level which I had hoped at the beginning of the project. Due to time constraints I did not have

the time to complete the search algorithms for the mouse. I also run out of time to make PCB’s

which I had hoped to do towards the beginning of the project.


26

Conclusions:

Positives:

I feel that this project has tested me in many ways. I have had to improve many skills such as circuit

design and also learn new ones such as cad modelling.

I think that getting a basic chassis early on in development was crucial to the rate at which we were

able to progress through the project. Having this from the beginning meant that we always had

hardware to test new software on, even in the first few weeks. This enabled us to continuously

develop both our software and hardware together, rather than trying to build hardware that worked

with the software we had already written.

Negatives:

I think that some of the tasks’ in the gannt chat were far too large and that many of them should

have been broken down further to make them more achievable.

I think that our time management could have been better and a few of our smaller deadlines were

missed. This adds up and meant that towards the end of the project there was a lot left to do. This

resulted in a few areas such as the flood fill not getting finished to the standard I had hoped for at

the beginning of the project.

I also think that it is a shame that we never had time to complete PCB’s for the mouse as I was

interested in trying to design boards that included surface mount components. We made sure that

each component that we used had a surface mount alternative. Unfortunately due to increased

workload In the second term I decided that it was not worth re-designing and re-building boards that

already worked on strip board.


27

What would I do differently next time?

I think that next time I undertake a large group project it needs to be organised so that more work is

done individually then collaborated as each section is finished. This allows many people to be

developing many different things at the same time. We found that we spent too much time at the

beginning of the project working on sections together and whilst this made things easier it was

actually far less productive.

Another thing that I will keep in mind next time I take on a project is that i must prioritize making big

decisions more. At the beginning of the project I put off making decisions about which batteries and

sensors we were going to use. Unfortunately I found out that not making these decisions started to

hold up development as I did not know which sensors to add to hardware designs and schematics.

Once the decisions had been mad I then had to wait the for the ordered sensors to arrive before I

could continue testing and finish designs.

Final Conclusion:

I feel that by the end of the project we had produced a small, professional mouse without

compromising on functionality. Our hardware met and in many cases exceeded our initial goals for

the project, including being smaller than our original targets. Our software, whilst not being fully

completed showed all of the important functionality needed to solve the maze and showed that

with more time the mouse would be capable of completing the task. The mouse is able to achieve a

high level of both control and accuracy whilst being a robust development platform.


28


Final Report

Appendix


29

Technical drawings:


30

Circuit diagram and strip board design:


31

Parts list with supplier codes and prices :

Part Supplier Order Code Cost per unit

Quantity Total cost (£)

PROTOBOARD, 100X160

Farnell 1201477 4.89 1 4.89

DSPIC33FJ128MC802-E/SP Farnell 1676256 5.49 1 5.49

L293D, dual H-bridge Farnell SC10241 2.09 1 2.09

SFH4550 - LED, 5MM IR 850NM

Farnell 1573495RL 0.44 4 1.76

BPW96B - PHOTOTRANSISTOR, NPN

Farnell 1470163 0.46 4 1.84

TRANSISTOR, PNP, TO-92 Farnell 1574372 0.128 1 0.128

HEADER, PIN, 2.54MM, 36WAY

Farnell 9729038 1.35 1 (strip of

36) 1.35

HEADER, SOCKET, 2.54MM, 36WAY

Farnell 9728856 1.87 1 (strip of

36) 1.87

SOCKET, DIP, 28WAY Farnell 1674794 2.23 1 2.23

SOCKET, DIP, 16WAY Farnell 1674786 1.07 1 1.07

L7805ABP - IC, REG LDO, 5V, 1A

Farnell 1564318 0.18 1 0.18

LM317LZ - IC, ADJ LINEAR REG

Farnell 1609393 0.11 1 0.11

LED, SMD, 0603, BLU Farnell 1686063RL 0.192 2 0.384

RESISTOR, 220R Farnell 1898506 0.068 1 0.068

RESISTOR, 0.1% 392R Farnell 1083207 0.122 1 0.122

RESISTOR, 0.1% 38R3 Farnell 1083099 0.18 1 0.18

RESISTOR, METAL FILM, 4.7KOHM,

Farnell 1129109 0.079 1 0.079

RESISTOR, 0.1% 3K83 Farnell 1083316 0.31 4 1.24

RESISTOR, 0.1% 3K32 Farnell 1083309 0.106 1 0.106

CAPACITOR, 2.2UF Farnell 3818937 0.025 1 0.025

CAPACITOR, 10NF Farnell 1216435 0.148 2 0.296

CAPACITOR, 10UF Farnell 1870986 0.048 1 0.048

SLIDE SWITCH, 1WAY Farnell 1203424 1.51 1 1.51

Solarbotics RW2i Wheel Active Robots

RW2i-3MM 2.75 2 5.50

Rhino 610mAh 7.4v RC

graveyard - 5.99 1 5.99

Total 31.902

*This costing does not include the DC motors or the cost of 3D printed parts as they were provided

for by the university.


32

Reflective Account

Queron Williams – 10031755

During this project I have realised that group work has the potential to be so much more productive

than working alone. At the beginning of the project Adam and I started working on each section

together and whilst this made the work a lot easier it was not much faster than doing each part

alone. As the term progressed we began to realise that splitting the workload between us and

working separately got work done a lot faster. I have realised that when working in a group it is not

necessary to be involved in each part of the process and that it is far more efficient if you delegate a

series of smaller jobs to each person.

I have also come to realise that each person in a group has their own style and way of doing things.

Often Adam and I did not agree about the way things were done, this slowed down the work that we

were trying to complete. Eventually we realised that if we let each other work in our own ways then

we could work much more efficiently and produce a higher standard of work.

I think that I am a strong character with good leadership qualities and I often find it easy to take

charge in many situations. This however that this can often make working in a group with no

particular leader difficult as often the group lacks coordination or focus. When one person attempts

to regain this focus it makes other members feel like they are trying to take charge. Whilst working

with Adam I tried to consult him on all decisions that were made and often discussed things with

him instead of just getting on with them.

Another problem I faced with working on this long term project was that I didn’t realise how much

things could change over the course of the project. I had chosen to work with Adam on this project

as I had experience working with him from last year and knew that we worked well together. When

I worked with Adam during previous projects he was an intelligent and reliable partner capable of

producing high quality work. Whilst group work in the first term was fine, I had never considered

that he would leave during the second term. This left me with a large workload to pick up and no

plan for this situation. I think I was able to cope well with the extra workload however I feel that

some areas of the mouse did not meet my original expectations because of this. I was disappointed

that by the end of the project there was no time to make a PCB for the mouse and that I never got

around to fully implementing the flood fill & route optimisation.

I feel that despite the major setbacks that I have faced I was still able to produce a high quality final

piece. I think that this shows I work to a high standard and that I am capable of maintaining this even

when under pressure. I have learnt many things about working with others and hope to apply this to

both future group projects and also to other areas of my work such as college interactions.

micromouse final report

Documents

micromouse robot

micromouse hardware

micromouse competition

standard micromouse

final report contributions

control report

conceptual design

hardware design constraints