SMART Project Report

Robotic
Specification and
Design
Team SMART
Rob Johnson
BEng (Hons) Electronic Engineering
Embedded Systems VI
Dr Tony Wilcox
April 2002
Embedded Systems VI
Robotic Specification and design
Contents
1
2
Introduction ...................................................................................................................................... 3
Project Definition ............................................................................................................................ 4
2.1
SMART Project Team .............................................................................................................. 4
2.2
Objectives:................................................................................................................................ 4
2.3
Assumptions ............................................................................................................................. 4
3 Analysis ............................................................................................................................................ 5
3.1
Project Management ................................................................................................................. 5
3.2
Microprocessor Device Selection ............................................................................................. 5
3.3
Sensor Selection ....................................................................................................................... 6
3.4
Interface Protocol ..................................................................................................................... 6
4 Functional Specification ................................................................................................................... 7
4.1
Environment ............................................................................................................................. 7
4.2
Chassis...................................................................................................................................... 7
4.3
Power Supply Unit.................................................................................................................... 7
4.4
The Mouse ................................................................................................................................ 7
4.5
Motor Board ............................................................................................................................. 8
4.6
Sensor Board ............................................................................................................................ 8
4.7
Inter-Processor Communications.............................................................................................. 8
Block Diagram ......................................................................................................................................... 9
Motor Control Board .............................................................................................................................. 10
Research ................................................................................................................................................. 10
Introduction ........................................................................................................................................ 10
Data Flow Diagrams........................................................................................................................... 10
Robot context diagram........................................................................................................................ 11
Robot flow diagram............................................................................................................................ 12
Driver flow diagram ........................................................................................................................... 13
Wheeling ............................................................................................................................................ 14
Speed control...................................................................................................................................... 15
Displacement, speed and acceleration calculation.............................................................................. 16
Communication protocol .................................................................................................................... 17
Path solving ........................................................................................................................................ 18
Wall following.................................................................................................................................... 20
Construct identification ...................................................................................................................... 21
Introduction .................................................................................................................................... 21
Straight wall.................................................................................................................................... 21
Inside corner ................................................................................................................................... 22
Outside corner ................................................................................................................................ 23
Dead End ........................................................................................................................................ 23
Hairpin............................................................................................................................................ 24
Hardware design..................................................................................................................................... 25
Introduction ........................................................................................................................................ 25
Block diagram .................................................................................................................................... 26
Microcontroller hardware requirements ............................................................................................. 27
Ports.................................................................................................................................................... 28
On-board I/O ...................................................................................................................................... 28
Circuit diagram................................................................................................................................... 29
Software design ...................................................................................................................................... 30
Introduction ........................................................................................................................................ 30
Robot structure chart .......................................................................................................................... 31
Driver structure chart.......................................................................................................................... 32
Driver state transition diagram ........................................................................................................... 33
Rob Johnson
E00766615
i
C:\DOCUME~1\PAULAS~1.STA\LOCALS~1\Temp\_ZCTmp.Dir\SMART.doc
Embedded Systems VI
Algorithms.............................................................................................................................................. 34
Path solver .......................................................................................................................................... 34
Wall follower...................................................................................................................................... 35
Target finder ....................................................................................................................................... 36
Home .................................................................................................................................................. 37
Position calculator .............................................................................................................................. 38
Run ..................................................................................................................................................... 39
Food Seeker........................................................................................................................................ 40
Scout................................................................................................................................................... 41
Speed control...................................................................................................................................... 42
RX I2C ............................................................................................................................................... 43
TX I2C................................................................................................................................................ 44
Cartographer ....................................................................................................................................... 45
Initialisation........................................................................................................................................ 46
Read Motor current............................................................................................................................. 47
Get motor current ............................................................................................................................... 48
Tachograph......................................................................................................................................... 49
Conclusions ............................................................................................................................................ 50
Bibliography........................................................................................................................................... 51
Appendix A Code ................................................................................................................................ 52
Test.c .................................................................................................................................................. 52
Timer.c ............................................................................................................................................... 55
Inter.c.................................................................................................................................................. 56
Appendix B Team skill distribution .................................................................................................... 57
Team Members Skills Assessment. .................................................................................................... 57
Hardware Skills .................................................................................................................................. 57
Software Skills.................................................................................................................................... 57
Access................................................................................................................................................. 57
Practical Skills (Mechanical & Electrical).......................................................................................... 58
Design................................................................................................................................................. 58
Algorithm Design ............................................................................................................................... 58
Report Writing.................................................................................................................................... 58
Appendix C - General Assembly Drawing ............................................................................................ 59
Rob Johnson
E00766615
ii
Embedded Systems VI
Introduction
1.6
The assignment is to develop a self contained, autonomous device that is capable of

avoiding obstacles, traversing a maze layout, and locating 'food'.
1.7
There are four main elements to the device (from now to be called the mouse), each
implementing different aspects of sensor, microprocessor and motor utilisation.
1.8
The first is that the mouse should be capable of traversing a predefined area detecting,
and hence avoiding, obstacles in its path. This capability demonstrates positional
sensing facilities linked to some intelligent motor control.
1.9
The second is the ability to follow a wall without contact with the wall, demonstrating
both improved sensor sophistication, for example range measurement, and intelligent
control of motor speed and direction determined from the sensor data.
1.10
Thirdly the mouse should be able to detect 'food' in the form of a light source
(incandescent bulb). Here the focus is on intelligent search processes, linked to sensors
capable of primarily determining direction, but still with some distance measuring
ability. Note the 'food' is a light source placed at random within the maze and may not
be detectable beyond the immediate wall.
1.11
Finally the mouse is to solve a maze, using the wall following capability, but with the
added facility to memorise the maze layout (not necessarily on the first attempt) with the
intention of completing a 'run' from start to finish in the shortest time possible,
completion being indicated by the entry of the mouse into the centre square of the maze.
Rob Johnson
E00766615
3
Embedded Systems VI
Project Definition
2.1
SMART Project Team

2.1.1
2.1.2
2.1.3
2.2
Objectives:
2.2.1
2.2.2
2.2.3
2.3
2.3.3
2.3.4
2.3.5
E00766615
To design, programme and construct an autonomous vehicle.

The vehicle will have the following capabilities:
2.2.2.1 Obstacle detection:
2.2.2.1.1 Enter random search pattern to identify a wall (identified as obstacle);
2.2.2.2 Obstacle Avoidance:
2.2.2.2.1 To avoid contact with wall/obstacle by detection of the wall/obstacle
and taking suitable action.
2.2.2.3 Wall Following:
2.2.2.3.1 To follow a path parallel to a wall without contact;
2.2.2.3.2 On completion of a circular route, revert to a random search.
2.2.2.4 Food Detection:
2.2.2.4.1 Identify food;
2.2.2.4.2 Head towards food using objectives 2.2.2 a, b, and c;
2.2.2.4.3 Stop and spin on spot to indicate detection.
2.2.2.5 Maze Solving
2.2.2.5.1 Negotiate and map maze, food detection will identify completion;
2.2.2.5.2 On subsequent runs improve/confirm map data;
2.2.2.5.3 Use map data to improve completion time of maze.
The budget will be acceptable to the TIC.
Assumptions
2.3.1
2.3.2
Rob Johnson
Robert Johnson
Anthony Wright
Andrew Carter
The TIC will provide the maze;

The TIC will provide the chassis, including two motors, gear-train, motor drivers
and optical wheel rotation sensors;
It will be possible to independently control the speed and direction of the motors;
TIC will provide the battery pack;
Laboratory temperature, lighting and noise levels will remain reasonably constant
throughout the demonstration time.
4
Embedded Systems VI
Analysis
3.1
Project Management
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.1.6
3.1.7
3.1.8
3.2
Microprocessor Device Selection

3.2.1
3.2.2
3.2.3
3.2.4
Rob Johnson
E00766615
The development team comprises three part time students, each with a varying
degree of skill in several disciplines. In order to efficiently and effectively
complete the assignment it is sensible to analyse the available skills, capabilities
and resources. This is particularly important as the team are geographically
dispersed.
Due to the fragmented geographic locations of the team members, and having
part-time university attendance then unacceptable limitations will be put on
development time if the assignment were undertaken in tutorial time only.
Therefore the team will rely on an individuals' access to a particular resource,
whether at work or home.
The requisite skills required to complete the mouse are expected to be:
3.1.3.1 Research;
3.1.3.2 Hardware design;
3.1.3.3 Programming;
3.1.3.4 Report writing;
3.1.3.5 Algorithm design;
3.1.3.6 Test and development;
3.1.3.7 Planning and co-ordination;
3.1.3.8 Technical co-ordination;
3.1.3.9 Mechanical construction capability.
One team member has chosen to investigate an area of particular interest that is
not an area of expertise, although is used in day-to-day work. This is to increase
the depth of knowledge in that area. To accommodate this it is prudent to have
two team members working in parallel to achieve the desired results within the
specified time frame.
The skills set also allowed for the splitting of the processing functions. This
enables the sensors and the motor drive areas to be developed separately, levelling
the workload within the team.
This processing function split leads to the requirement for a suitable interface
protocol for data transfer between the processors.
The meeting of 12-02-02 determined the results of the skills analysis, this being:
3.1.7.1 Andrew Carter - Sensor research (detection and food), algorithm design,
CAD drawing and documentation, hardware build.
3.1.7.2 Rob Johnson - Motor drive hardware design, algorithm design,
microprocessor programming, technical co-ordination.
3.1.7.3 Anthony Wright - Sensor interface hardware design, sensor backup,
algorithm design, microprocessor programming and project timetable.
3.1.7.4 Common skills - Report writing, mechanical construction, test and
development.
Therefore all the required skills are divided to allow a roughly equal tasking
between team members.
The processor type selected was dependent on the availability of development

tools such as compilers and programmers, and the teams skill range and
resources.
Two team members had good 'C' programming capabilities, free access to
development systems, and the necessary hardware to program the Microchip PIC
range of processors.
The final choice was the Microchip range of devices. These are available with a
range of I/O (including analogue), memory (ROM and RAM), wide operating
power supply range, very fast clock frequencies and are relatively inexpensive.
The inclusion of memory (code and RAM) and peripherals within the PIC chip
means there are no specific concerns regarding timing constraints to interface
these parts, easing circuit design and subsequent development.
5
Embedded Systems VI
3.3
Sensor Selection
3.3.1
3.3.2
3.3.3
To implement non-contact wall following and object detection the choice is

between ultrasonic transducers and infrared LED's. The ultrasonic transducers
were selected due to their ability to return the distance of an object over a vastly
increased linear range compared to the infrared LED, albeit at a slightly higher
cost overall.
Microswitches were to be incorporated at each corner of the board to allow for
dead-reckoning errors and/or to confirm a position should an error occur.
Food sensing was to be implemented to locate the light based 'food' elements,
consisting of a binocular pair of light dependent resistors (LDR) for depth
perception (range) and directional capability. These are to be located on the front
of the mouse only.
3.4
Interface Protocol
3.5
The I2C format (at 100kHz) as defined by Philips Ltd was chosen. The PIC 16F877
incorporates dedicated pins and registers to implement this protocol, as did the compiler
used for code production. This again was chosen to ease development time and effort.
Rob Johnson
E00766615
6
Embedded Systems VI
Functional Specification
4.1
Environment
4.1.1
4.1.2
4.1.3
4.1.4
4.1.5
4.1.6
4.2
Chassis
4.2.1
4.2.2
4.3
4.3.3
4.3.4
4.3.5
4.4.3
4.4.4
4.4.5
4.4.6
4.4.7
4.4.8
E00766615
The power supply unit will be wholly provided by the TIC.

9.6VDC NI-CAD batteries (final specification to be determined) will
provide the power source.
The unit will regulate the supply down to 5VDC although both voltages
will be available.
The batteries will have a self-charging function when not in use.
The power supply should be capable of running the micromouse for 15
minutes non-stop without interruption.
The Mouse
4.4.1
4.4.2
Rob Johnson
Mouse chassis (motor, gearbox, wheel and sensor) is as supplied by TIC

The TIC motor control board will provide the motor drive interface, comprising of
a power drive circuit, optical disk sensor with amplifier and reversing relay per
drive as per the electrical and mechanical specification provided in the Embedded
Systems VI module guide.
Power Supply Unit

4.3.1
4.3.2
4.4
All tasks are to be performed in a nominally constant room temperature,

approximately 20 C;
All tasks are to be performed in nominally constant lighting levels;
All tasks are to be performed at nominally constant background sound levels.
The maze floor will be level and flat throughout.
The maze walls and general dimensions will conform to micromouse competition
rules.
Only one micromouse will be active in the maze at any one time.
The mouse is to be fully autonomous.

The length and width of the mouse shall be restricted to a square of 250mm x
250mm, but with no height restriction or width restriction above 50mm (the height
of the wall).
Electrical interconnections are to be via multi-way cable connectors where
possible.
The micromouse shall capable of operating in three distinct, but related, modes of
operation - wall follower, maze solver and food detection.
The user initiates the required mode of operation.
RS232 serial communications links will be integrated to any microcontrollers for
diagnostic purposes.
De-bugging pushbuttons and LEDs will be provided (2 off of each) for use in
development.
Micromouse stability will be accomplished with a skid-plate in constant contact
with the maze floor. This will double up as an aid to stop the mouse flipping over
under acceleration.
7
Embedded Systems VI
4.5
Motor Board
4.5.1
4.5.2
4.5.3
4.5.4
4.5.5
4.6
Control the motors individually to provide forward, backward and steering

(directional) control.
For the obstacle avoidance task, respond to sensor data regarding the distance and
bearing of an obstacle and either stop, then re-orient, or make suitable directional
changes to avoid collision with the obstacle.
For the wall following task, respond to data from (and interrogate sensor board if
required) to maintain an essentially parallel path to the wall (including inside and
outside corners).
For the food detection task, implement a search routine to locate food source and,
once detected, head towards the source avoiding obstacles in the path.
Provide a data link with the Sensor board to either receive regular data or request
specific sensor(s) be read via the I2C bus.
Sensor Board
4.6.1
Provide all-round object sensing for collision avoidance and distance

measurement.
4.6.1.1 Detect objects in the direction of travel at sufficient distance to allow the
mouse to take corrective action before collision can occur.
4.6.1.2 Detect the wall to the side of the mouse at sufficient distance to allow the
mouse to correct any directional errors to maintain a path parallel to the
wall, avoiding contact with the wall.
4.6.1.3 Signal an 'out-of-range' condition from a sensor, but continue scan sequence.
4.6.2
Provide forward binocular direction and range sensing for 'food' detection.
4.6.3
Provide a data link with the Motor board to either send regular data updates or
respond to requests for sensor(s) to be read via the I2C bus.
4.6.4
Powered from the main battery pack, with on-board power supply regulation.
4.7
Inter-Processor Communications
4.7.1
4.7.2
4.7.3
Rob Johnson
E00766615
Based on the I2C protocol by Philips.

Requires two-wire link, Clock and Data.
Each processor is capable of Master and Slave operation.
8
Embedded Systems VI
Block Diagram
POSITION
POSITION
MOTOR 1
MOTOR 2
DIRECTION
GEARING
POWER
INTERFACE
DIRECTION
MASTER
MICROCONTROLLER
SPEED
POWER
INTERFACE
SPEED
IC
SLAVE
MICROCONTROLLER
8 OFF
MICROSWITCHES
Rob Johnson
E00766615
INTERFACE
CIRCUITRY
INTERFACE
CIRCUITRY
6OFF
ULTRASONIC
TRANSMITTERS
6 OFF
ULTRASONIC
RECEIVERS
9C:\DOCUME~1\PAULAS~1.STA\LOCALS~1\Temp\_ZCTmp.Dir\SMART.doc
GEARING
Embedded Systems VI
Motor Control Board

Research
Introduction
From the analysis of skills undertaken from by the team it was decided that Rob (myself) should
undertake the design of the motor control board. It was decided that the design should incorporate all
the tasks set in the brief, even if they are not eventually implemented, in order to prove the robot would
be capable of completing the tasks.
From the functional specification, produced by the group, a data flow diagram was derived to identify
the major processes required by the motor control board in order to make it capable of completing all
the specified tasks. The following section details the development of the data flow diagram. Where
necessary the tasks identified by the data flow diagram were researched in order to find enable
algorithms to be produced to implement them. This section of the report provides an overview of the
research that was undertaken. In some cases it was deemed appropriate to present the results and/or
conclusions from the research in this section.
Data Flow Diagrams

As the data flow diagrams were produced it became obvious that the processes that were being
identified fell into two sections; the real time processes that must be implemented with in specific time
frames and the back ground tasks that did not have real time constraints. Due to the complexity of
showing all processes on a single diagram and to highlight the real time/background split of the
processes the diagram was separated in two, with the process Driver indicating the background tasks
on the parent sheet.
The real time processes developed a further divide, between those reacting to external influences and
those that required scheduling on a regular time basis. The control process depicts the overall control
of the program. This process simply enables or disables the processes required to react to external
sources and triggers the scheduled processes from a real time clock. Control of background tasks is far
simpler and the control process simply triggers the processes as appropriate.
Rob Johnson
E00766615
10
Embedded Systems VI
Robot context diagram
Sensor board
Set
measurements
Light Info
Range
Give reading
Switches
Robot
Distance
travelled
PWM
Direction
Mode
Over current
User
Rob Johnson
E00766615
Right motor
control
Embedded Systems VI
Robot flow diagram

Switc hes
Light Info
Set
meas urements
I2C interfac e
G iv e reading
5
Range
Switc hes
Required
meas urements
E/D
Dis tanc es
Light Info
Switc hes
Dis tanc es
Required
meas urements
Dis tanc es
Required
meas urements
Cartographer
7
Mode
Switc hes
Pos ition/O rientation
Run
meas urements
E/D
T ime
Map
Time
Dis tanc es
Driv er
Multiplex or
11
PWM c ontrol
6
Voltages
Path
Run
E/D
E/D
T
E/D
Voltages
12
Pos ition
Calc ulator
Voltages
Motor c urrent
Counter
Dis tanc e
Dis tanc e
Motor c urrent
Distanc e
Speed Control
T
Ac c elerations
Motor c urrent
Distanc e
Speeds
Ac c elerations
Read and
c onv ert
Ac c elerations
T ac ograph
Speeds
Distanc e
trav elled
10
Speeds
Motor s peeds
O v er c urrent
Motor s peeds
Motor Speeds
Rob Johnson
E00766615
Direc tion
PWM
Embedded Systems VI
Driver flow diagram
Map
Mode
Control
driving
T
T
Target
T
Map complete
Scouter
Found
Light Info
Light Info
Map
T
Map
Map
Light Info
Map
Home
7
T
Food seeker
4
Required
position
Required
position
T
Required
position
Map
Required
position
T
Position/Orientation
Path solver
Rob Johnson
E00766615
Path
Path
Position
Path
Embedded Systems VI
Wheeling
In order for the robot to turn without coming to a complete stop it will be necessary for the robot to
wheel or follow an arc around a corner. In order to do this the speed for each wheel must be altered
and the difference in speed between the two wheels decides the radius of the arc. Consider the diagram
below:
w
r
rl
rr
Rob Johnson
E00766615
The robot wishes to turn in an arc with a radius of r, in

the direction indicated by the arrow. In order to
achieve this the left wheel must follow a circle of
radius rl and the right hand wheel a circle of radius rr.
The difference between the two radii will be w, the
width of the robot. From C = 2r, the distance
travelled by each wheel in one complete circle would
be:
Cl = 2(r-w/2)
Cr = 2(r+w/2)
Hence the relationship between the speeds should be:
(2r-w)/(2r+w)
14
Embedded Systems VI
Speed control
In order to enable the robot to move in straight lines or wheel around corners speed control will be
required on the motors. Some initial practical analysis was carried out using a prototype motor driver
board, improvised for the purpose. Some very primitive algorithms were designed to simply increment
or decrement the voltage to the motor dependant on either speed or acceleration feedback (See
appendix A for the complete code listing used for the results below). Data collected from the runs was
stored in RAM and then dumped via the serial communications lead at the end of the run. The results
of a acceleration feedback speed control is shown below, the steady state speed should be 10, neither
axis has been calibrated:
Speed and Acceleration response
14
12
10
Speed/Acceleration
6
Acceleration
Speed
0
0
10
15
20
25
30
35
-2
-4
-6
Time
The results were reasonable, with the speed averaging around 10, but the response was far from ideal
with a very long (if not infinite) settling time. To overcome this a Proportional-Integral-Derivative
(PID) controller can be implemented. Initially the mathematics of this appeared difficult to implement,
given the processing power of the hardware and the time constraints of the project however, as the
controlled variable is speed and we are differentiating and integrating with respect to time the three
variables required are easily available:
d(speed)
= displacement
d(time)
speed d(time) = acceleration

Although the true calculus cannot be performed the displacement feedback from the drive assembly can
be sampled over a short enough time period to give a good approximation. The relative influence of
each controller required to obtain the best response will be identified empirically.
It was also discovered that care needed to be taken with regard to the time over which the displacement
feedback is sampled. Due to the graduation of the toothed wheel for the optical sensors sampling the
sensors too often caused ambiguous results i.e. if samples were taken between two teeth of the wheel,
the displacement (and hence speed and acceleration) was be assumed to be zero, even when the wheel
was moving. Equally at high speeds sampling too infrequently could cause the control loops reaction
to be too slow. In order to accommodate both extremes samples should be taken very quickly and a
running average used for calculation.
Rob Johnson
E00766615
15
Embedded Systems VI
Displacement, speed and acceleration calculation

In order for the robot to calculate its position with in a given area it can either utilise information from
the displacement feedback from the drive assembly relative to a known starting position or use the
analogue distance sensors relative to a known obstacle.
The displacement sensors have the problem of cumulative errors; every wheel spin, skid and variation
of direction will be compounded in the position calculation. For this reason it is considered better to
use the analogue distance sensors to accurately position the robot from walls or other obstacles.
Displacement sensors will only be use for position when no obstacles are in range.
It is believed that speed and acceleration calculations should be undertaken using the drive assemblys
displacement sensors. The problem of cumulative errors is over come with speed and acceleration as
the displacement is integrated over a small period of time hence the errors cannot compound. The time
taken for the analogue sensors to return distances and the calculation to convert these to appropriate
speeds for each motor would make these sensors impractical in this instance, hence the small errors
encountered by the displacement sensors must be tolerated.
Rob Johnson
E00766615
16
Embedded Systems VI
Communication protocol
The sensor board needs to pass information to the motor controller regarding the distances to the walls,
the direction of the food and the status of the switch sensors. It was felt that an interface between the
two systems should be specified as early in the design as possible to allow independent development of
each board. The following specifies the interface.
The switch sensors have been included as a back up measure to indicate there has been a problem with
the analogue sensors. This means that information from the switches is generally redundant; the
switches will be open and navigation can be undertaken from the analogue sensors. If the switches do
close this indicates a problem and the motor controller needs to react as quickly as possible to stop
motors stalling, the corruption of maze data due to wheel spin etc. These requirements lean themselves
towards interrupt driven messages for the switches i.e. the sensor board will immediately transmit when
and only when the switches change state.
The light and analogue distance sensors are required whenever the motor controller needs to navigate;
this leans itself towards a polling system. Time could be a concern when travelling at high speeds and
often many of the readings will be superfluous (e.g. only front and one sides sensors will be required to
follow a single wall), so to minimise time taken for the readings, only the required sensors will be
requested. This leads to two message types; a set-up command from the motor controller to the sensor
board followed by several read messages.
The interface will use Phillips I2C interface.
This will implemented using the MSSP on both the sensor and the motor microcontroller.
7 bit addressing will be used on the I2C bus.
Three message formats will be defined between the controllers.
The first message format defines which sensors the motor controller wishes to read. Each bit that is set
means the Sensor board will reply with that value when read. This message will take the form of a
master (motor board) transmit, slave (sensor board) read:
Address Byte
Distance sensors
Auxiliary sensors
Ack
Spare
Spare
Spare
Spare
TL
Spare
BB
LR
Back
LB
Target located
Left Back
LF
LL
Left Front
RB
Light Right
Right Back
RF
Light left
Right Front
FR
Ack
Front Right
FL
Spare
Front Left
Ack
R/W
Address
Once the required sensors have been set multiple reads can be made with out the required sensor
information being updated again. This message will be of the form master (motor board) read, slave
(sensor board) write. Each sensor will reply with a single byte. Each increment of the byte will be a
5mm graduation from 0 to 254. 255 will indicate no wall has been detected.
If a switch sensor is operated the sensor controller will enter master transmit mode and inform the
motor controller. The message will take the following format. Setting the relevant bit indicates the
switch has been operated by the wall:
Address Byte
Switches
Front Right
Right Front
Right Back
Left Front
Left Back
Back Left
Back Right
FL
FR
RF
RB
LF
LB
BL
BR
Ack
Front Left
Ack
R/W
Address
Common library functions will be defined for both controllers to implement the communications.
Rob Johnson
E00766615
17
Embedded Systems VI
Path solving
An integral part of the mouse solving the maze was a path solver, an algorithm that would choose a
route between two given points. Solving a path by inspection was easy, but developing a consistent
algorithm proved more difficult so more formal, mathematical methods were investigated. The most
appropriate discovered was Djikstars algorithm.
Djikstars algorithm was identified as a means of identifying the shortest path between two points. In
its basic form it took a map and transformed it into a network, anywhere there was a choice of direction
became a node and each link between nodes was given a number relating to the distance between those
nodes. A sample network is given below:
A
T
4
3
B
From the starting point, S, all directly accessible nodes were then labelled with the distance from the
start to that point. The lowest number was then made permanent (boxed in the example):
2
A
T
4
3
B
3
The process was then repeated starting from the label last made permanent; temporary labels were only
replaced if a new label was lower:
2
A
T
4
3
B
3
Once the label at the Target node had been made permanent the shortest route was identified by tracing
the route where the distance between two nodes is equal to the difference between the two labels on
those nodes:
2
A
T
4
T B = 6 3 = 3 5 so not T B
T A = 6 2 = 4 = 4 so go T B
A B = 2 3 = -1 4 so not a B
A S = 2 0 = 2 = 2 so go A S
Hence the shortest route is S A T.
B
3
Rob Johnson
E00766615
18
Embedded Systems VI
This method was then appropriated to the mouse by assuming every cell is a node and hence the
distance between the nodes could only be 1. Starting at the target, T, the maze map was filled with
incrementing labels:
A
When the destination, the shaded cell, was reached, following the decrementing count identified the
shortest path to the target cell.
The path then has to be stored so as the mouse can navigate it. In order to do this the path is split into
straight runs and the end of each run to be stored. So path will store the following cells:
C2, C1, D1, D0.
It has been considered that the shortest route is not necessarily the fastest; cornering takes a
considerable amount of time but is not considered in the above method. It was possible to take this into
account by adding a larger number to the cells after a turn and then applying Djikstars algorithm fully.
Due to the time constraints on this project it was considered unnecessary to implement this.
Rob Johnson
E00766615
19
Embedded Systems VI
Wall following
Wall following was to be utilised in both the wall following and the maze solving section of the robot.
Maze solving guarantees that a wall will always be present on at least one side of the mouse, general
wall following does not. In order to reduce code implementation, test and maintenance time it was
decided to combine bot these areas into a single process. For this reason the research below assumes
the robot may start a reasonable distance from the wall it wishes to follow.
Wall following has been segregated into three stage, the first two being the approach and the third, the
run parallel to the wall. This should provide a relatively fast approach to a wall without having to come
to complete stops, turning and then continuing:
First stage
Gently wheel around to
a perpendicular
approach.
Second stage
Wheel around
more sharply than
first stage to a 45
approach. Speed
should slow to stop
overshooting in to
the wall.
Third stage
The robot sharply wheels
around perpendicular to the
wall, then accelerates with
fine adjustments.
See the section on Wheeling for further explanation of the turns.

An alternative considered was a two stage approach, the first satge a single whee and the second
identical to the third stage descibed above. It was intended to calculate, from trigonometery, an
aopproprite radius and angle through which the robot would turn in a single arc. This was disgarded
because of the large amount of calculation required.
Rob Johnson
E00766615
20
Embedded Systems VI
Construct identification
Introduction
This section attempts to identify the wall constructs the robot may encounter. Further to this the
perspectives from which the robot may approach the various constructs were considered and hence a
means of identifying the various constructs and adapting to them was developed. Finally any
difficulties for the sensing system were identified
For this report it has been assumed that the robot will be equipped with the following array of sensors.
F
L1
R1
L2
R2
B
F = Forward
B = Backward
L1 = Left 1
L2 = Left 2
R1 = Right 1
R2 = Right 2
The arrow indicates the direction of travel.
Each sensor is expected to return a distance to the
closest wall if any.
A table in each description list the sensors, the
second column indicates what is expected from that
sensor: 0 = no wall detected, 1 = a wall in range, X =
this sensor is not relevant in this situation, ? = unsure
of result practical experimentation required.
In order to simplify the identification process most approaches attempt to align the robot with a wall
and then treat the manoeuvre as following a straight wall.
Straight wall
F
0
B
X
L1
1
L2
0
R1
X
R2
X
Continue to allow second sensor to identify
wall.
Take corrective action for distance and
parallel orientation to the wall.
Parallel
F
L1
R1
L2
R2
B
F
1
B
X
L1
1
L2
0
R1
X
R2
X
Continue to allow second sensor to identify
wall.
Arc to right to until F loses contact with wall
Treat as parallel approach.
Angled
R1
F
R2
L1
B
L2
Perpendicular
R1
R2
L1
F
B
L1
L2
R1
R2
1
X
0
0
X
X
L2
Turn to right until L1 contacts wall.

Treat as an angled approach.
Rob Johnson
E00766615
21
Embedded Systems VI
Inside corner
B
F
L1
R1
From known
wall
A
L2
R2
B
F
B
L1
L2
R1
R2
1
X
1
1
X
X
Turn 90 to the right treat wall B as a

straight wall.
B
R1
F
R2
F
B
L1
L2
R1
R2
1
X
1
1
X
X
L1
B
L2
From angle
Rob Johnson
E00766615
Initially appears to be angles approach to

flat wall, but when L1 = L2, F is still in
contact with wall.
If distance to wall B allows treat as angled
approach to flat wall A, then perpendicular
approach to inside corner.
If forward distance is not large enough,
treat as perpendicular approach to wall B.
22
Embedded Systems VI
Outside corner
F
L1
R1
L2
F
B
L1
L2
R1
R2
R2
B
Parallel approach
1
X
0
1
X
X
Continue until L2 loses wall A.

Continue until clear of wall A.
Turn through 90 degrees.
Continue forward until L1 identifies wall B.
Treat as parallel to straight wall B.
Angled approach
R1
F
R2
L1
B
L2
F
1
B
X
L1
1
L2
0
R1
X
R2
X
Treat as angled approach to a straight wall followed by
a parallel approach to an outside corner.
Dead End
R2
B
R1
L2
F
L1
F
?
B
X
L1
0
L2
0
R1
0
R2
0
Potential
hazard, sensing
F
0 wave may be dispersed
from
B receiver.
X
Headon
approach
F
L1
R1
L2
R2
Head-on
Rob Johnson
E00766615
L1
1
L2
X
R1
1
R2
X
Can only be approached head on.
Treat wall A as straight wall.
23
Embedded Systems VI
Hairpin
F
B
L1
L2
R1
R2
F
L1
R1
L2
R2
B
Parallel
1
X
0
1
X
X
Continue until L2 loses wall.

Continue until clear of wall.
Continue forward distance from front to L1.
L1 does not detect wall, continue until clear of wall.
Continue until L1 finds wall.
Treat as parallel approach to straight wall.
R2
B
L2
R1
F
L1
Head-on
F
B
L1
L2
R1
R2
?
X
0
1
X
X
Potential problem may not be identified!
Rob Johnson
E00766615
24
Embedded Systems VI
Hardware design
Introduction
Once the research into the processes necessary to implement the functional specification was complete
the actual design was then considered. To simplify this task it was broken down into its hardware and
software elements; the hardware design is dealt with first in this report.
The functional specification and the processes highlighted by the data flow diagrams, produced earlier,
were considered and the relevant hardware sections required to implement these processes were
identified. The these hardware sections were then documented in a general block diagram to indicate
there interrelationships. From this a processor was chosen, the I/O defined and finally the complete
circuit was designed. This section details and documents this process.
Rob Johnson
E00766615
25
Embedded Systems VI
Block diagram
Mode
selection
Mode select
Reset
circuitry
Clock
circuitry
RS232
driver
Reset
2
Motor driver
Debug
Dig I/O
Debug Inputs
CPU
Clock
2
Debug Outputs
Backplane 1
Direction
14
2
Speed
Motor control
4
Distance
Feedback
PWM
Counters
UART
Serial
E2RAM
RS232
3
Motor current
Motor
driver
interface
RS232
connector
Motor current
Over-voltage
protection
A2D
PC
Null modem
9
Battery voltage
1
Sensor
board
TBA
Battery voltage
1
Backplane 2
Power supply
14
Sensor
board
interface
Power supply decoupling
Power supply
3
ISP
2
Sensor info
2
IC
controller
ISP
ISP
3
ISP
connector
3
Power
2
Micro controller
Motor control board
Rob Johnson
E00766615
Programmer
Embedded Systems VI
Microcontroller hardware requirements

The initial investigation into the resources available to the group, undertaken by the group, suggested
that a PIC microcontroller should be utilised if appropriate. The hardware block diagram was
examined to identify the exact blocks hardware support required form the microcontroller. These
requirement were then drawn up into the table given below and compared to those available in the
multitude of PIC microcontrollers available. The PIC16F877 was able to fulfil all requirements and
hence has been chosen to be the microcontroller to implement on the target system. This choice was
consolidated with personal experience of the processor gained during Embedded Systems IV.
Peripheral/Feature
Counter
Qty
2
Timer
UART
Bus system
PWM outputs
Analogue to digital converter
channels
Digital outputs
1
1
1
2
2
Digital inputs
Programming facility for ROM,

preferably ISP
ROM
RAM
Rob Johnson
E00766615
1
1
Requirement
Displacement feedback from drive
assembly
Co-ordinate real time events
Debug
Communication to sensor board
Motor speed control
Detect motor current
2 for direction control
2 for debug
2 for mode selection
2 for debug
For updating development code
For holding program
Data memory for program and
maze map
Availability
Timer/Counter 0 and 1
Timer 2
USART
2
MSSP (I C)
CCP 1 and 2
8 channel A/D
General purpose I/O pins
General purpose I/O pins (with
interrupts available)
In-circuit Serial Programming
8K program word flash
368SRAM + 256EEPROM
27
Embedded Systems VI
ISP
In-circuit serial
program
RS232 debug
port
For connection
to PC via Nullmodem lead
Motor board
interface
Backplane 1
Sensor board
interface
Backplane 2
(modified)
1
2
3
4
5
1
2
3
4
5
6
7
8
9
10
1
2
3
4
5
6
7
8
9
10
11
12
13
14
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Description
Direction1
Name
Pin
Port
Ports
+5V
Vpp
PGD
PGC
0V
O
I
B
B
O
Programmer is powered by the target board

To be connected to Vpp pin on PIC (Pin 1)
Program Data to be connected to RB7 (Pin 40)
Program clock to be connected to RB6 (Pin 39)
Power supply and reference
RX
TX
I
O
Data receive
Data transmit
GND
Signal ground
CTS
RTS
I
O
Clear to send (Not implemented, linked to CTS)

Ready to send (Not implemented, linked to RTS)
+5V
VBAT
RDIR
LDIR
RDRV
LDRV
RCUR
LCUR
ROPT
LOPT
RBRK
LBRK
GND
GND
S1D
S1A
S2D
S2A
S3D
S3A
S4D
S4A
SS1
VBAT
SDA
CLK
+5V
GND
I
I
O
O
O
O
I
I
I
I
I
I
I
I
I
I
I
I
I
I
O
O
B
B
O
O
Spare
+5V supply to board 100mA max?
Battery power supply
Right direction control
Left Direction control
Right speed control
Left speed control
Voltage representing current through right motor
Voltage representing current through left motor
Pulse input representing right motor displacement
Pulse input representing right motor displacement
Not implemented on driver board
Not implemented on driver board
Sensor 1 digital input
Sensor 1 analogue or digital 2 input
Slot select 1
Supply for sensor board
Serial data bi-directional
Serial data clock
Supply for sensor board
I = Input, O = Output, B = Bi-directional.
On-board I/O
On-board
I/O
Name
Debug
outputs
Debug
inputs
Mode
selection
Reset
LED1
LED2
SWT1
SWT2
MOD1
MOD2
RST
Rob Johnson
E00766615
Description
Lamp and test-points drive low to light lamps
Momentary pushes (N/O)
Jumper links to select mode of operation
Momentary push (N/O) resets the device
28
Embedded Systems VI
Circuit diagram
Rob Johnson
E00766615
Embedded Systems VI
Software design
Introduction
The second stage of the design was the software. Again the functional specification and the data flow
diagrams were considered and the processes were converted into a structure chart, defining the
functions required by the design. As with the data flow diagrams the distinction between real time and
background tasks was apparent. Again this differentiation was shown with a separation of drawings.
The real time tasks had a control module that simply calls the relevant tasks at relevant time, many of
the tasks are interrupt driven hence are not called by the control function. The background tasks are
entirely scheduled by the control module and this operation was detailed with a State Transition
Diagram. All other modules have been documented with flow charts. Many of the modules formed
directly from the research carried out earlier, and this section formalised the algorithms that were
developed.
Rob Johnson
E00766615
30
Embedded Systems VI
Robot structure chart

System manager
Initialisation
User
Mode
Get motor
current
Driver
Position
calculator
Travelled
distances
Travelled
distances
Position
Travelled
distances
TX I2C
Acceleration
Required measuements
Give reading
Tacograph
Orientation
Speed
Setmeasurements
Required
measurements
Acceleration
5
Sensor board
Travelled
disances
Acceleration
Speed
Switches
Rerquired measurements
Range
Speed
Counter
Cartographers
measurements
Light
info
Speed control
Cartographer
RX I2C
Map
Position
Measured
distances
Travelled
distances
Required
speeds
Orientation
Light
info
3
Required speed
Measured
distances
Light Info
4
Voltages
Measured
distances
Light
info
Measured
distances
Required
speeds
Run measurements
Directions
Motor currents
Wall
Motor currents
Run
Measured
distances
Wall follower
Read motor
current
Motor current
Motor currents
Switches
Switches
Position
Path
Orientation
Switches
Rob Johnson
E00766615
Motor driver
board
Embedded Systems VI
Driver structure chart

Driver
1
Light
info
Map complete
Light
info
Scout
Target
Required
position
Map
Home
Food Seeker
Light Info
Required
position
Map
5
Required
position
Map
Position
Orientation
Map
Required
position
Position
Map
Position
Position
Orientation
Path solver
Path
Path
Path
2
Rob Johnson
E00766615
Embedded Systems VI
Driver state transition diagram
Reset
"Mode"
T: Food seeker
Deciding where
food is
Decided
T: "Path solver"
E: Run
Done
T: Food seeker
Heading
for food
Mapped
T: Scout
Deciding where
to scout
"Mode"
T: Scout
Mapping
Decided
T: "Path solver"
E: "Run"
"Map complete"
T: "Home"
T: "Path solver"
E: "Run"
Finding home
"Found"
T: "Home"
T: "Path solver"
E: "Run"
"Found"
T: Target
T: "Path solver"
E: "Run"
Rob Johnson
E00766615
Finding target
Embedded Systems VI
Path solver
Algorithms
Set count to zero
Path solver
Identify destination cell
Required
position
Place count in cell(s)
Decrement count
Yes
Are any of the current

cells the destination?
No
Increment count
Find cell directly accessible from current

cell containing the count
Mark as route
No
Identify all cells directly accessible from the

current cell(s)
Has the destination

cell been reached?
Yes
Identify start cell
Does robot have to

turn to get to next
cell?
Yes
Note cell in Path
No
Identify next cell
No
Is this the destination

cell?
Yes
Identify next cell
Path
End Path solver
Rob Johnson
E00766615
34
Map
Embedded Systems VI
Wall follower
Wall follower
Is robot within
perpendicular
distance?
Yes
Wheel towards perpendicular to wall
No
Head perpendicular to wall
No
Is robot within 45
distance?
Head 45 to wall
No
Yes
Yes
Yes
Is robot perpendicular
to wall?
Wheel towards 45 to wall.
Is robot 45 to wall?
Is robot within fine

adjustment distance?
Yes
Is robot heading
towards wall?
Yes
Small wheel away from wall
No
Small wheel towards wall
No
Is wall still there?
Yes
End Wall follower
Rob Johnson
E00766615
No
35
No
Embedded Systems VI
Target finder
Target finder
Map
Find target
Solve path
End Target finder
Rob Johnson
E00766615
36
Path
Embedded Systems VI
Home
Home
Identify home
Solve path
Path
End home
Rob Johnson
E00766615
37
Embedded Systems VI
Position calculator
Position calculator
Distance
travelled
Calculate X distance travelled
Orientation
Calculate Y distance travelled
Position
Add distance travelled to last Position
Calculate distance to known walls from

Position
Is data available form

measured distances?
Yes
No
Store Position
End Position calculator
Rob Johnson
E00766615
38
Modify Position
Embedded Systems VI
Run
Run
Is current position the

same as required
position?
No
Yes
Are there any more

positions in the path?
No
Yes
Get next position to go to
Head to target
End run
Rob Johnson
E00766615
39
Embedded Systems VI
Food Seeker
Food seeker
Is light found?
Yes
No
Light info
Is left sensor greater

than right?
Yes
No
Is left sensor less

than right?
Find position to the left
Position
Yes
Find position to the right
No
Find position straight ahead
Solve path
End Food seeker
Rob Johnson
E00766615
40
Embedded Systems VI
Scout
Scout
Map
Are there any

unmapped areas?
Yes
No
Identify unmapped area
Solve path
End Scout
Rob Johnson
E00766615
41
Return map complete
Embedded Systems VI
Speed control
Speed Control
Required
speed
Calculate: Proportional gain (Required

speed Current speed)
Speed
Calculate: Derivative gain (Required

acceleration Current acceleration)
Acceleration
Calculate: Derivative gain (Required

distance Current distance)
Distance
Sum results and store in required voltage
End speed control
Rob Johnson
E00766615
42
Embedded Systems VI
RX I2C
RX I2C
Distances
Is data switch info?

Yes
Store switch info
No
Store info at pointer
Light info
Distances
Have all distances
been stored?
No
Yes
Move on to next distance
Move on to next distance
End RX I2C
Rob Johnson
E00766615
43
Embedded Systems VI
TX I2C
TX I2C
Set up measurements
No
Are required readings

same as last?
Yes
Request measurements
End TX I2C
Rob Johnson
E00766615
44
Required
measurements
Embedded Systems VI
Cartographer
Cartographer
Position
Locate position on map
Orientation
Identify orientation on map
Measured
distances
Approximate distances to edge of cells
Mark known walls on map
End cartographer
Rob Johnson
E00766615
45
Map
Embedded Systems VI
Initialisation
Initialisation
Initialise variable
Initialise hardware
Enable interrupts
End Initialisation
Rob Johnson
E00766615
46
Embedded Systems VI
Read Motor current

Read motor current
Get value from A2Ds
Store as current values
Motor
currents
End Read motor current
Rob Johnson
E00766615
47
Embedded Systems VI
Get motor current
Get motor current
Start A2D Conversions
End Get motor current
Rob Johnson
E00766615
48
Embedded Systems VI
Tachograph
Tachograph
Speed
Calculate distance
Current
distance
Calculate acceleration
Current
distance
Calculate speed
End Tachograph
Rob Johnson
E00766615
49
Embedded Systems VI
Conclusions
The design of the motor control board has progressed well, with all aspects of the functional
specification complete. The paper design has been reinforced with practical experimentation with code
and hardware. The compiler and programmer have been tested with the chosen processor and a stable
development platform has been produced. A reduced motor drive board has been produced,
implementing, unidirectional PWM, opto-interrupter feedback, ISP and serial communications. This
has proved the basic building blocks of the hardware and allowed for initial research of some of the
software algorithms.
The group has worked well as a team. Identifying the skills available within the group very early on in
the project has made a major impact in ensuring the tasks were allocated not only evenly but also to the
best advantage of the group. The allocation of tasks has and the minimising of coupling between those
tasks meant that each member ahs been able to progress individually and delays waiting for other
members have been minimised. This was singularly important due to the part time mode of study
leaving little contact time for the team. Good progress has been made through out the group and the
robot is well advanced. The sensor board has been prototyped and is giving stable results (see other
reports for details). The overall general assembly has also been considered (see appendix C for
drawing) and appropriate components sourced ready for the final build.
The completion of the design, including the areas undertaken by the rest of the group, and the
implementation of relevant development tools means the robot is now well poised for implementation.
Although the robot is currently running to our time scales it is intended to phase the implementation.
This is due to the large amount of work required and the minimal amount of time available. The
hardware and software implementation has been split to allow them to run concurrently to save time.
The phased implementation is intended to ensure the maximum number of functions are implemented
fully rather than all functions being partially implemented.
Overall the project is well poised; the design is complete, the implementation underway and the team is
working well together. The team has overcome the difficulties of communicating while so
geographically separated and there is a felling of reasonable confidence that at least some of the robots
functions will be successfully completed.
Rob Johnson
E00766615
50
Embedded Systems VI
Bibliography
www.swallow.com
University of Michigan, www.engin.umich.edu/group/ctm/PID/PID.html, PID tutorial.
Robot Science and Technology, 2nd, 3rd and 4th issue.
www.microchip.com
Microchip Inc, PIC16F877 datasheet.
Rob Johnson
E00766615
51
Embedded Systems VI
Appendix A Code
Test.c
/* TimerA is left hand motor
Timer1 is right hand motor */
#include <16f877.h>
#include <math.h>
#include <stdlib.h>
#pragma
#pragma
#pragma
#pragma
#pragma
#pragma
#pragma
#pragma
#pragma
#pragma
FUSES HS, NOWDT, NOPROTECT, PUT, BROWNOUT, NOLVP, NOCPD, WRT

use delay(clock=20000000)
use RS232 (baud=19200, xmit=PIN_C6, rcv=PIN_C7, parity=N, bits=8)
bit LeftMotor = 0x06.5
bit RightMotor = 0x06.4
byte IntCon = 0x0b
byte PR2 = 0x92
byte CCPR1L = 0x15
byte T2CON = 0x12
byte CCP1CON = 0x17
#define NUM_SAMPLES 10
#define NUM_SPEEDS 5
#define AIM_SPEED 10
signed int LeftPower, RightPower; /* Percentage power (0 to 100) */
unsigned int LeftHist[NUM_SAMPLES], RightHist[NUM_SAMPLES];
unsigned long int LeftDist, RightDist;
unsigned long Tick;
unsigned long int LastLeft, LastRight;
short int Go;
#include "timers.c"
#include "inter.c"
signed int adjust_power(unsigned int Speed, signed int Acceleration, unsigned int
Aim);
void main()
{
unsigned
int
i,
j,
LeftSpeed,
RightSpeed,
RightSpeedHist[NUM_SPEEDS];
unsigned int AdjResult[30], SpeedIndex;
signed int AdjResult2[30];
short int FirstTime;
signed int LeftAcceleration, RightAcceleration;
LeftSpeedHist[NUM_SPEEDS],
init_tmr();
set_tris_b(0x00);
for (i = 0; i < NUM_SAMPLES; i++)
LeftHist[i] = RightHist[i] = 0;
for (i = 0; i < NUM_SPEEDS; i++)
LeftSpeedHist[i] = RightSpeedHist[i] = 0;
LastLeft = LastRight = LeftPower = RightPower = LeftSpeed = RightSpeed =
LeftAcceleration = RightAcceleration = LeftDist = RightDist =0;
enable_interrupts(global);
puts("Start up\n\r");
for(;;)
{
while (getchar() != 'g') /* Wait for go command */
LeftPower = RightPower = 0;
disable_interrupts(global);
Tick = 00;
set_timera(00);
set_timer1(00);
LeftHist[i] = RightHist[i] = 0;
for (i = 0; i < NUM_SPEEDS; i++)
Rob Johnson
E00766615
52
Embedded Systems VI
LeftSpeedHist[i] = RightSpeedHist[i] = 0;
LastLeft = LastRight = LeftSpeed = RightSpeed = LeftAcceleration =
RightAcceleration = LeftDist = RightDist =0;
enable_interrupts(global);
while (get_timer1() < 500)
{
if (!(Tick % 2))
{
if (FirstTime)
{
LeftSpeed = RightSpeed = 0;
LeftSpeed += LeftHist[i];
RightSpeed += RightHist[i];
if (++SpeedIndex > NUM_SPEEDS)
SpeedIndex = 0;
LeftAcceleration
=
(signed
int)(LeftSpeed
RightAcceleration
LeftSpeedHist[SpeedIndex]);
=
(signed
int)(RightSpeed
RightSpeedHist[SpeedIndex]);
LeftSpeedHist[SpeedIndex] = LeftSpeed;
RightSpeedHist[SpeedIndex] = RightSpeed;
LeftPower
+=
adjust_power(LeftSpeed,
RightPower
+=
adjust_power(RightSpeed,
LeftAcceleration, AIM_SPEED);
RightAcceleration, AIM_SPEED);
if (LeftPower > 100)
LeftPower = 100;
if (LeftPower < 0)
LeftPower = 0;
if (RightPower > 100)
RightPower = 100;
if (RightPower < 0)
RightPower = 0;
FirstTime = FALSE;
if ((!(Tick % 10)) && (j < 30))
{
if (j > 0)
{
AdjResult[(j - 0)] = LeftSpeed;
AdjResult2[(j - 0)] = LeftPower;
}
j++;
}
}
}
else
FirstTime = TRUE;
}
printf("TimerA
%06lu
Timer1
%06lu\n\r",
get_timera(),
get_timer1());
for (j = 0; j < 30; j++)
printf("LeftPower = %03D, LeftSpeed = %03U \r\n", AdjResult2[j],
AdjResult[j]);
j = 0;
}
}
Rob Johnson
E00766615
53
Embedded Systems VI
#define ADJ_RES 1
signed int adjust_power(unsigned int Speed, signed int Acceleration, unsigned int Aim)
{
signed int SpeedError, RequiredAcceleration;
if (!((Speed == Aim) && (!Acceleration))) /* Speed is constant and correct; do
nothing. */
{
SpeedError = Aim - Speed;
if (SpeedError > 5)
RequiredAcceleration = 4;
else if (SpeedError > 0)
RequiredAcceleration = 2;
else if (SpeedError < -5)
RequiredAcceleration = -4;
else
RequiredAcceleration = -2;
if (Acceleration != RequiredAcceleration)
{
if (Acceleration < RequiredAcceleration)
return (1);
else
return (-1);
}
}
return (0);
}
Rob Johnson
E00766615
54
Embedded Systems VI
Timer.c
unsigned long int TimerA;
void init_tmr();
void set_timera(long Value);
long get_timera();
void init_tmr()
{
set_rtcc(0x00);
setup_counters(RTCC_EXT_L_TO_H, WDT_2304MS); /* Timer0 counter for left motor
*/
set_timer1(0x00);
setup_timer_1(T1_EXTERNAL | T1_DIV_BY_1);
/* Timer1 counter for right motor
*/
set_timer2(0x00);
setup_timer_2(T2_DIV_BY_1, 199, 1);
/* Timer2 used as a 8 bit counter to give a
system tick (40uS) */
enable_interrupts(int_timer2);
enable_interrupts(int_rtcc);
IntCon |= 0x40;
}
long get_timera()
{
return(get_timer0() + TimerA);
}
void set_timera(long Value)
{
TimerA = (Value - (Value % 256));
set_timer0((int)(Value & 0xff));
}
#pragma INT_RTCC
void timera_overflow()
{
TimerA += 256;
}
Rob Johnson
E00766615
55
Embedded Systems VI
Inter.c
/*
Modifies:
Uses:
LeftDist
RightDist
Tick
LeftPower
RightPower
*/
#pragma INT_TIMER2
void pwm_control()
{
static unsigned int Period, Hist;
static signed int LeftCount, RightCount;
if (!(Period--)) /* Check if the PWM period has elapsed */
{
LeftDist = get_timera(); /* Get the current distance */
RightDist = get_timer1();
RightMotor = LeftMotor = 1;
Tick++;
/* Start Mark */
/* System tick to give background tasks time info */
Period = 100;
if (++Hist >= NUM_SAMPLES)
Hist = 0;
LeftHist[Hist] = (unsigned int)(LeftDist - LastLeft);
RightHist[Hist] = (unsigned int)(RightDist - LastRight);
LastLeft = LeftDist;
LastRight = RightDist;
LeftCount = LeftPower;
RightCount = RightPower;
}
if (--LeftCount < 0)
LeftMotor = 0; /* Start Space */
if (--RightCount < 0)
RightMotor = 0; /* Start Space */
}
Rob Johnson
E00766615
56
Embedded Systems VI
Appendix B Team skill distribution

Date:
Topics:
Attendees:
12 February 2002
Super Mouse, Skills, Objectives, Future Actions.
Robert Johnson
Andrew Carter
Anthony Wright
Team Members Skills Assessment.

Team members assessed their own ability in a number of disciplines. The scoring method used was as
follows.
1 High
2 Medium
3 Low
4 None
Hardware Skills
The following table gives an indication of the experience in integrating the hardware and associated
circuitry of a number of different microcomputers that could be used on the Super Mouse project.
196
3
3
3
Robert
Andrew
Anthony
PIC
1
2
1
8051
2
3
2
AVR
2
4
4
Software Skills
The following table gives an indication of the experience in integrating the software and various
languages associated with a number of different microcomputers that could be used on the Super
Mouse project.
Robert
Andrew
Anthony
Assembler
2
3
1
Forth
2
2
2
C
1
2
1
Basic
2
2
2
Access
The following table gives an indication of the resources available to team members. The assessment
takes into consideration the time that the various resources are available to the team member and
whether that resource contains both the hardware and software element of the microcomputer.
Robert
Andrew
Anthony
Rob Johnson
E00766615
196
3
3
3
PIC
1
2
1
8051
3
4
3
57
AVR
1
4
3
Embedded Systems VI
Practical Skills (Mechanical & Electrical)

The following table gives an indication of the practical skills possessed by each team member. The
availability of these resources has also been taken into account during the scoring process and is shown
in the second column.
Skill Level
1
1
1
Robert
Andrew
Anthony
Access/Time
1
1
1
Design
The following table gives an indication of the design skills possessed by each team member. The
availability of the various design packages has also been taken into account during the scoring process
and is shown in the second column.
Skill Level
1
1
1
Robert
Andrew
Anthony
Access/Time
1
1
2
Algorithm Design
Skill Level
1
1
1
Robert
Andrew
Anthony
Report Writing
The following table gives an indication of the report writing skills possessed by each team member.
The availability of PCs etc has also been taken into account during the scoring process and is shown in
the second column.
Robert
Andrew
Anthony
Rob Johnson
E00766615
Skill Level
1
1
1
Access/Time
1
1
1
58
Embedded Systems VI
Appendix C - General Assembly Drawing
Rob Johnson
E00766615

SMART Project Report

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SMART Project Report

Uploaded by

Copyright:

Available Formats

Robotic

Robotic Specification and design

Robotic Specification and design

Robotic Specification and design

The assignment is to develop a self contained, autonomous device that is capable of

Robotic Specification and design

SMART Project Team

To design, programme and construct an autonomous vehicle.

The TIC will provide the maze;

Robotic Specification and design

Microprocessor Device Selection

The processor type selected was dependent on the availability of development

Robotic Specification and design

To implement non-contact wall following and object detection the choice is

Robotic Specification and design

The power supply unit will be wholly provided by the TIC.

Mouse chassis (motor, gearbox, wheel and sensor) is as supplied by TIC

Power Supply Unit

All tasks are to be performed in a nominally constant room temperature,

The mouse is to be fully autonomous.

Robotic Specification and design

Control the motors individually to provide forward, backward and steering

Provide all-round object sensing for collision avoidance and distance

Based on the I2C protocol by Philips.

Robotic Specification and design

Robotic Specification and design

Motor Control Board

Data Flow Diagrams

Robotic Specification and design

Robot context diagram

Robotic Specification and design

Robot flow diagram

Pos ition/O rientation

Pos ition/O rientation

Pos ition/O rientation

Robotic Specification and design

Driver flow diagram

Robotic Specification and design

The robot wishes to turn in an arc with a radius of r, in

Robotic Specification and design

speed d(time) = acceleration

Robotic Specification and design

Displacement, speed and acceleration calculation

Robotic Specification and design

Robotic Specification and design

Robotic Specification and design

Robotic Specification and design

See the section on Wheeling for further explanation of the turns.

Robotic Specification and design

Turn to right until L1 contacts wall.

Robotic Specification and design

Turn 90 to the right treat wall B as a

Initially appears to be angles approach to

Robotic Specification and design

Continue until L2 loses wall A.

Robotic Specification and design

Continue until L2 loses wall.

Potential problem may not be identified!

Robotic Specification and design

Robotic Specification and design

Power supply decoupling

Robotic Specification and design

Microcontroller hardware requirements

Programming facility for ROM,