robotic - tic.ac.uk filerobotic specification and design team smart rob johnson beng (hons)...

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

Rob Johnson i C:\DOCUME~1\PAULAS~1.STA\LOCALS~1\Temp\_ZCTmp.Dir\SMART.doc E00766615

Contents 1 Introduction ......................................................................................................................................3 2 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 ii C:\DOCUME~1\PAULAS~1.STA\LOCALS~1\Temp\_ZCTmp.Dir\SMART.doc E00766615

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 3 C:\DOCUME~1\PAULAS~1.STA\LOCALS~1\Temp\_ZCTmp.Dir\SMART.doc E00766615

1 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.



2 Project Definition

2.1 SMART Project Team 2.1.1 Robert Johnson 2.1.2 Anthony Wright 2.1.3 Andrew Carter

2.2 Objectives: 2.2.1 To design, programme and construct an autonomous vehicle. 2.2.2 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.

2.2.3 The budget will be acceptable to the TIC.

2.3 Assumptions 2.3.1 The TIC will provide the maze; 2.3.2 The TIC will provide the chassis, including two motors, gear-train, motor drivers

and optical wheel rotation sensors; 2.3.3 It will be possible to independently control the speed and direction of the motors; 2.3.4 TIC will provide the battery pack; 2.3.5 Laboratory temperature, lighting and noise levels will remain reasonably constant

throughout the demonstration time.



3 Analysis

3.1 Project Management 3.1.1 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.

3.1.2 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.

3.1.3 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.

3.1.4 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.

3.1.5 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.

3.1.6 This processing function split leads to the requirement for a suitable interface protocol for data transfer between the processors.

3.1.7 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. 3.1.8 Therefore all the required skills are divided to allow a roughly equal tasking

between team members.

3.2 Microprocessor Device Selection

3.2.1 The processor type selected was dependent on the availability of development tools such as compilers and programmers, and the team’s skill range and resources.

3.2.2 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.

3.2.3 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.

3.2.4 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.



3.3 Sensor Selection

3.3.1 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.

3.3.2 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.

3.3.3 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.



4 Functional Specification

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

approximately 20° C; 4.1.2 All tasks are to be performed in nominally constant lighting levels; 4.1.3 All tasks are to be performed at nominally constant background sound levels. 4.1.4 The maze floor will be level and flat throughout. 4.1.5 The maze walls and general dimensions will conform to micromouse competition

rules. 4.1.6 Only one micromouse will be active in the maze at any one time.

4.2 Chassis 4.2.1 Mouse chassis (motor, gearbox, wheel and sensor) is as supplied by TIC 4.2.2 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.

4.3 Power Supply Unit 4.3.1 The power supply unit will be wholly provided by the TIC. 4.3.2 9.6VDC NI-CAD batteries (final specification to be determined) will

provide the power source. 4.3.3 The unit will regulate the supply down to 5VDC although both voltages

will be available. 4.3.4 The batteries will have a self-charging function when not in use. 4.3.5 The power supply should be capable of running the micromouse for 15

minutes non-stop without interruption.

4.4 The Mouse 4.4.1 The mouse is to be fully autonomous. 4.4.2 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).

4.4.3 Electrical interconnections are to be via multi-way cable connectors where possible.

4.4.4 The micromouse shall capable of operating in three distinct, but related, modes of operation - wall follower, maze solver and food detection.

4.4.5 The user initiates the required mode of operation. 4.4.6 RS232 serial communications links will be integrated to any microcontrollers for

diagnostic purposes. 4.4.7 De-bugging pushbuttons and LED’s will be provided (2 off of each) for use in

development. 4.4.8 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.



4.5 Motor Board 4.5.1 Control the motors individually to provide forward, backward and steering

(directional) control. 4.5.2 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.

4.5.3 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).

4.5.4 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.

4.5.5 Provide a data link with the Sensor board to either receive regular data or request specific sensor(s) be read via the I2C bus.

4.6 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 Based on the I2C protocol by Philips. 4.7.2 Requires two-wire link, Clock and Data. 4.7.3 Each processor is capable of Master and Slave operation.


Rob Johnson 9C:\DOCUME~1\PAULAS~1.STA\LOCALS~1\Temp\_ZCTmp.Dir\SMART.doc E00766615

5 Block Diagram

SPEED SPEED

I2C

DIRECTION DIRECTION

POSITION POSITION

POWER

INTERFACE

POWER

INTERFACE

GEARING

GEARING

MOTOR 1

MOTOR 2

8 OFF

MICROSWITCHES

INTERFACE CIRCUITRY

INTERFACE CIRCUITRY

6OFF

ULTRASONIC TRANSMITTERS

6 OFF

ULTRASONIC RECEIVERS

MASTER

MICROCONTROLLER

SLAVE

MICROCONTROLLER



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.



Robot context diagram

Robot

Sensor board

Right motorcontrol

User

Range

Switches

PWM

Direction

Over current

Distancetravelled

Mode

Give reading

Setmeasurements

Light Info



Robot flow diagram

Speed Control

2

PWM control

3

Voltages

Read andconvert

4

I2C interface

5

DistancesSwitches

Motor current

Counter

9

Distance

Tacograph

10

Driver

11

Speeds

Accelerations

Motor Speeds

Time

Multiplexor

6

PositionCalculator

1

Cartographer

7

Requiredmeasurements

Run

12

Range

Switches

Over current

Distancetravelled

Voltages

Voltages

Give reading

Setmeasurements

Light Info

Distances

Runmeasurements

Light Info

Switches

Motor current

Distance

Distance

Distances

Switches

Motor current

Mode

T

Speeds

Accelerations Speeds

Accelerations

Motor speeds

Motor speeds

Time

E/DE/D

T

T

E/D

T E/D

T

Distance

Position/Orien-tation

Distances


MapE/D



Path


PWM

Direction



Driver flow diagram

Path solver

2

Scouter

3

Food seeker

4

Controldriving

6

Home

7

Path

Map

Target

1

Position/Orie-ntation

Light InfoLight Info Map

Mode

Map

Path

T

T

T

T

Found

Map complete

Position


Requiredposition

Requiredposition

Requiredposition

Map

Map

Map

Requiredposition

T

TT

T

T

Path



Light Info



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:

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 = 2πr, 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)

w

r

rl rr



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:

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:

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.

Speed and Acceleration response

-6

-4

-2

0

2

4

6

8

10

12

14

0 5 10 15 20 25 30 35

Time

Spee

d/A

ccel

erat

ion

AccelerationSpeed

∫ =

=

onacceleratid(time) speed

ntdisplacemed(time)d(speed)



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 assembly’s 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.



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 Phillip’s 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 Front Left

Front Right

Right Front

Right B

ack

Left Front

Left Back

Back

Spare

Light left

Light Right

Target located

Spare

Spare

Spare

Spare

Spare

Address

0 0 0 0 0 1 R/W

Ack

FL

FR

RF

RB

LF

LB

BB

Ack

LL

LR

TL

Ack

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 Left

Front Right

Right Front

Right B

ack

Left Front

Left Back

Back Left

Back R

ight

Address

0 0 0 0 1 0 R/W

Ack

FL

FR

RF

RB

LF

LB

BL

BR

Ack

Common library functions will be defined for both controllers to implement the communications.



6

S

T

A 2

3

4

5

4

B

2

3

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 Djikstar’s algorithm. Djikstar’s 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:

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):

The process was then repeated starting from the label last made permanent; temporary labels were only replaced if a new label was lower:

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:

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.

S

T

A 2

3

4

5

4

B

S

T

A 2

3

4

5

4

B

2

3

6

S

T

A 2

3

4

5

4

B

2

3



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 B C D

0 5 6 7 T

1 4 3 2 1

2 5 4 3 2

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 Djikstar’s algorithm fully. Due to the time constraints on this project it was considered unnecessary to implement this.



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:

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.

Third stage The robot sharply wheels around perpendicular to the wall, then accelerates with fine adjustments.

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.



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.

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 L1

L2

R1

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.

F L1

L2

R1

R2 B

Parallel

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.

F

L1

L2

R1

R2

B

Angled 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.

F

L1 L2

R1 R2

B

Perpendicular F 1 B X L1 0 L2 0 R1 X R2 X

Turn to right until L1 contacts wall. Treat as an angled approach.



Inside corner

F 1 B X L1 1 L2 1 R1 X R2 X

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.

F

L1

L2

R1

R2

B

From angle

A

B

F 1 B X L1 1 L2 1 R1 X R2 X

Turn 90° to the right treat wall B as a straight wall.

F L1

L2

R1

R2 B

From known wall A

B



Outside corner

Dead End

F L1

L2

R1

R2 B

Head—on approach

F ? B X L1 0 L2 0 R1 0 R2 0

Potential hazard, sensing wave may be dispersed from receiver.

F L1

L2

R1

R2 B

Parallel approach

A

B F 1 B X L1 0 L2 1 R1 X R2 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.

F 0 B X L1 1 L2 X R1 1 R2 X

Can only be approached head on. Turn through 180 degrees. Treat wall A as straight wall.

F L1

L2

R1

R2 B

Head-on

A

F

L1

L2

R1

R2

B

Angled approach

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.



Hairpin

F L1

L2

R1

R2 B

Parallel

F 1 B X L1 0 L2 1 R1 X R2 X

Continue until L2 loses wall. Continue until clear of wall. Turn through 90 degrees. Continue forward distance from front to L1. L1 does not detect wall, continue until clear of wall. Turn through 90 degrees. Continue until L1 finds wall. Treat as parallel approach to straight wall.

F L1

L2 R1

R2 B

Head-on

F ? B X L1 0 L2 1 R1 X R2 X

Potential problem may not be identified!



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.



Block diagram

Backplane 1 14

Backplane 2 14

RS232 driver

Clock circuitry

Power supply de-coupling

Over-voltage protection

Motor driver

interface

Motor driver

Sensor board

Sensor board

interface

RS232 connector

ISP connector

PC

Programmer

Debug

A2D

Counters

Reset circuitry

PWM

Dig I/O

ISP

I2C controller

Distance2

Motor current2

Debug Inputs2

Speed2

Direction2

Power supply3

Power supply3

Sensor info2

UART Serial2

RS2323

ISP3

TBA ?

Power2

Null modem9

ISP3

CPU

E2RAM

Reset1

Clock2

Motor current2

Battery voltage1

Battery voltage1

Feedback2

Micro controller

Motor control board

Debug Outputs2

Motor control4

Mode selection

Mode select2



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 Qty Requirement Availability Counter 2 Displacement feedback from drive

assembly Timer/Counter 0 and 1

Timer 1 Co-ordinate real time events Timer 2 UART 1 Debug USART Bus system 1 Communication to sensor board MSSP (I2C) PWM outputs 2 Motor speed control CCP 1 and 2 Analogue to digital converter channels

2 Detect motor current 8 channel A/D

Digital outputs 4 2 for direction control 2 for debug

General purpose I/O pins

Digital inputs 4 2 for mode selection 2 for debug

General purpose I/O pins (with interrupts available)

Programming facility for ROM, preferably ISP

1 For updating development code In-circuit Serial Programming

ROM 1 For holding program 8K program word flash RAM 1 Data memory for program and

maze map 368SRAM + 256EEPROM



Ports

Port

Pin

Nam

e

Dire

ctio

n1

Des

crip

tion

1 +5V O Programmer is powered by the target board 2 Vpp I To be connected to Vpp pin on PIC (Pin 1) 3 PGD B Program Data to be connected to RB7 (Pin 40) 4 PGC B Program clock to be connected to RB6 (Pin 39)

ISP In-circuit serial

program

5 0V O Power supply and reference 1 2 RX I Data receive 3 TX O Data transmit 4 5 GND - Signal ground 6 7 CTS I Clear to send (Not implemented, linked to CTS) 8 RTS O Ready to send (Not implemented, linked to RTS) 9

RS232 debug port

For connection to PC via Null-modem lead

10 Spare 1 +5V I +5V supply to board 100mA max? 2 VBAT I Battery power supply 3 RDIR O Right direction control 4 LDIR O Left Direction control 5 RDRV O Right speed control 6 LDRV O Left speed control 7 RCUR I Voltage representing current through right motor 8 LCUR I Voltage representing current through left motor 9 ROPT I Pulse input representing right motor displacement

10 LOPT I Pulse input representing right motor displacement 11 RBRK - Not implemented on driver board 12 LBRK - Not implemented on driver board 13 GND I Power supply and reference

Motor board interface

Backplane 1

14 GND I Power supply and reference 1 S1D I Sensor 1 digital input 2 S1A I Sensor 1 analogue or digital 2 input 3 S2D I Sensor 2 digital input 4 S2A I Sensor 2 analogue or digital 2 input 5 S3D I Sensor 3 digital input 6 S3A I Sensor 3 analogue or digital 2 input 7 S4D I Sensor 4 digital input 8 S4A I Sensor 4 analogue or digital 2 input 9 SS1 O Slot select 1

10 VBAT O Supply for sensor board 11 SDA B Serial data bi-directional 12 CLK B Serial data clock 13 +5V O Supply for sensor board

Sensor board interface

Backplane 2 (modified)

14 GND O Power supply and reference

1 I = Input, O = Output, B = Bi-directional.

On-board I/O On-board I/O

Name Description

LED1 Debug outputs LED2

Lamp and test-points drive low to light lamps

SWT1 Debug inputs SWT2

Momentary pushes (N/O)

MOD1 Mode selection MOD2

Jumper links to select mode of operation

Reset RST Momentary push (N/O) resets the device



Circuit diagram



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.



Robot structure chart

System manager

Light Info

Switches


Measureddistances

Motor current

TravelleddistancesTX I2C

DriverGet motorcurrent

Counter

Tacograph

Speed control

RX I2C

Read motorcurrent

Initialisation

Motor driverboard

Sensor board

Required speed

1

User

Positioncalculator

Cartographer

Acceleration

Speed

3

Run

4

5

2

4

Wall follower

Lightinfo

Switches

Measureddistances

Travelleddisances

Rerquired measurements

Required measuements

Voltages

Motor currents

Travelleddistances

Directions

Setmeasurements

Give reading

Lightinfo

Range

Switches

Travelleddistances

Lightinfo

Motor currents

Switches

Run measurements

Requiredspeeds

Requiredspeeds

Measureddistances

Motor currents

Mode

Acceleration

Speed

Speed

Acceleration

Cartographersmeasurements

Measureddistances

Map

Travelleddistances

Position

Orientation

Position

Orientation

Path

Position

Orientation

WallMeasureddistances



Driver structure chart

Driver

Map

Food SeekerScout Home

Path

1

Path solver

Position

Target Light Info

2

3

4

5

Map complete

Map

Lightinfo

Requiredposition

Position/Orientation

Position

Requiredposition

Map

MapRequiredposition

Requiredposition

Path

Lightinfo

Path

Map

Position Orientation

Position

Orientation



Driver state transition diagram

Headingfor food

Finding home

Deciding whereto scout

Deciding wherefood is

Finding target

Mapping

"Mode"T: Scout

"Map complete"T: "Home"

T: "Path solver"E: "Run"

DoneT: Food seeker

DecidedT: "Path solver"

E: Run

"Mode"T: Food seeker

"Found"T: Target


"Found"T: "Home"


Reset

DecidedT: "Path solver"

E: "Run"

MappedT: Scout



Algorithms

Path solver

Path solver

Map

Set count to zero

Place count in cell(s)

Identify destination cell

Increment count

Identify all cells directly accessible from the current cell(s)

Are any of the current cells the destination?

Decrement count

Find cell directly accessible from current cell containing the count

Mark as route

Has the destination cell been reached?

Identify start cell

Does robot have to turn to get to next

cell?

Identify next cell

Is this the destination cell?

Note cell in Path

Path

End Path solver

Required position

Yes

No

Yes

No

Yes

No

No

Identify next cell

Yes



Wall follower

Wall follower

Is robot within perpendicular

distance?

Wheel towards perpendicular to wall

Is robot within 45° distance?

Wheel towards 45° to wall.

Small wheel towards wall

End Wall follower

Is robot heading towards wall?

Small wheel away from wall

Is robot perpendicular to wall?

Head perpendicular to wall

Is robot within fine adjustment distance?

Head 45° to wall Is robot 45° to wall?

Is wall still there?

Yes

Yes

Yes

Yes

No

No

No

No

No

Yes

Yes

No

No

Yes



Target finder

Target finder

Solve path

Map

End Target finder

Find target

Path



Home

Home

Solve path

End home

Identify home

Path



Position calculator

Position calculator

Calculate X distance travelled Distance travelled

Orientation Calculate Y distance travelled

Add distance travelled to last Position Position

Calculate distance to known walls from Position

Modify Position Is data available form measured distances?

Store Position

End Position calculator

Yes

No



Run

Run

Is current position the same as required

position?

Are there any more positions in the path?

Get next position to go to

End run

Yes

Yes

Head to target

No

No



Food Seeker

Food seeker

Is light found?

Is left sensor greater than right?

Find position to the right Is left sensor less

than right?

Find position to the left

End Food seeker

Solve path

Position

Light info

No

Yes

Find position straight ahead

No

Yes

No

Yes



Scout

Scout

Are there any unmapped areas?

Return map complete

Map

End Scout

Solve path

Identify unmapped area

No

Yes



Speed control

Speed Control

Calculate: Proportional gain (Required speed – Current speed)

End speed control

Calculate: Derivative gain (Required acceleration – Current acceleration)

Calculate: Derivative gain (Required distance – Current distance)

Sum results and store in required voltage

Speed

Acceleration

Distance

Required speed



RX I2C

RX I2C

Is data switch info?

Have all distances been stored?

Store info at pointer

Move on to next distance

End RX I2C

Distances

Light info

Store switch info

Distances

Yes

Yes

Move on to next distance

No

No



TX I2C

TX I2C

Are required readings same as last?

Request measurements

Set up measurements

End TX I2C

Required measurements

Yes

No



Cartographer

Cartographer

Locate position on map

Identify orientation on map

Approximate distances to edge of cells

Mark known walls on map Map

Orientation

Position

End cartographer

Measured distances



Initialisation

Initialisation

Initialise variable

Initialise hardware

Enable interrupts

End Initialisation



Read Motor current

Read motor current

Get value from A2Ds

Store as current values Motor currents

End Read motor current



Get motor current

Get motor current

Start A2D Conversions

End Get motor current



Tachograph

Current distance

Calculate acceleration

Calculate speed

Tachograph

End Tachograph

Speed

Calculate distance

Current distance



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 robot’s functions will be successfully completed.



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.



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 FUSES HS, NOWDT, NOPROTECT, PUT, BROWNOUT, NOLVP, NOCPD, WRT #pragma use delay(clock=20000000) #pragma use RS232 (baud=19200, xmit=PIN_C6, rcv=PIN_C7, parity=N, bits=8) #pragma bit LeftMotor = 0x06.5 #pragma bit RightMotor = 0x06.4 #pragma byte IntCon = 0x0b #pragma byte PR2 = 0x92 #pragma byte CCPR1L = 0x15 #pragma byte T2CON = 0x12 #pragma 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, LeftSpeedHist[NUM_SPEEDS], RightSpeedHist[NUM_SPEEDS]; unsigned int AdjResult[30], SpeedIndex; signed int AdjResult2[30]; short int FirstTime; signed int LeftAcceleration, RightAcceleration; 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); 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 = LeftSpeed = RightSpeed = LeftAcceleration = RightAcceleration = LeftDist = RightDist =0; LeftPower = RightPower = 15; enable_interrupts(global); while (get_timer1() < 500) { if (!(Tick % 2)) { if (FirstTime) { LeftSpeed = RightSpeed = 0; for (i = 0; i < NUM_SAMPLES; i++) LeftSpeed += LeftHist[i]; for (i = 0; i < NUM_SAMPLES; i++) RightSpeed += RightHist[i]; if (++SpeedIndex > NUM_SPEEDS) SpeedIndex = 0; LeftAcceleration = (signed int)(LeftSpeed - LeftSpeedHist[SpeedIndex]); RightAcceleration = (signed int)(RightSpeed - RightSpeedHist[SpeedIndex]); LeftSpeedHist[SpeedIndex] = LeftSpeed; RightSpeedHist[SpeedIndex] = RightSpeed; LeftPower += adjust_power(LeftSpeed, LeftAcceleration, AIM_SPEED); RightPower += adjust_power(RightSpeed, 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; } LeftPower = RightPower = 0; 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; } }



#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); }



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; }



Inter.c /* Modifies: LeftDist RightDist Tick Uses: 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; /* Start Mark */ Tick++; /* 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 */ }



Appendix B – Team skill distribution

Date: 12 February 2002 Topics: Super Mouse, Skills, Objectives, Future Actions. Attendees: 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 PIC 8051 AVR Robert 3 1 2 2 Andrew 3 2 3 4 Anthony 3 1 2 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.

Assembler Forth C Basic Robert 2 2 1 2 Andrew 3 2 2 2 Anthony 1 2 1 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.

196 PIC 8051 AVR Robert 3 1 3 1 Andrew 3 2 4 4 Anthony 3 1 3 3



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 Access/Time Robert 1 1 Andrew 1 1 Anthony 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.


Algorithm Design

Skill Level Robert 1 Andrew 1 Anthony 1

Report Writing The following table gives an indication of the report writing skills possessed by each team member. The availability of PC’s etc has also been taken into account during the scoring process and is shown in the second column.




Appendix C - General Assembly Drawing

robotic - tic.ac.uk filerobotic specification and design team smart rob johnson beng (hons)...

Documents