GPS Rover Final Report

Submitted By Team 9 Nicholas Jakobsen Shamik Raja Grigoris Eglesos Seung Park Vicky He Wen Sean Bin Wu Supervisor: Tom De Rybel EECE 375/474 Spring 2006 Department of Electrical and Computer Engineering University of British Columbia April 4, 2006

Abstract
This project consists of a mobile robot vehicle which can be controlled using data from an onboard GPS unit and a remote laptop base station. The robot uses advanced communication mediums in order to control and monitor its movement. Although the robot itself has a limited use, the purpose of developing the vehicle is a proof of concept. The combined technology used in this project may lead to future development in the area of GPS navigation. A GPS receiver is used to determine the current location of the robot. A wireless communications device with WiFi capability captures the GPS raw data from the receiver and transmits the data to a base station. Based on the GPS data readings, the base station calculates the direction the robot needs to travel in order to reach the final destination. The base station does not take into account the mechanical issues with the physical structure of the robot or the obstacles that may be in the way of the vehicle. The base station sends data and commands via wireless link to a microprocessor onboard the vehicle. The microprocessor controls the physical motion of the vehicle, taking into account the obstacles that may be in the way and adjusts the steering accordingly. There are always accuracy issues in any mechanical device. Some of the issues include wheel slippage, steering adjustments and speed of communication between mechanical and electrical devices. The microprocessor provides the control and speed to handle these mechanical problems and adjusts the robots motion accordingly.

Table of Contents
1 2 3 4 INTRODUCTION PROJECT BACKGROUND DESIGN REQUIREMENTS AND GOALS RESULTS 4.1 PROJECT OVERVIEW 4.1.1 Motorola 68HC11 Microprocessor 4.1.2 DC Motor Driving Circuit 4.1.3 Stepping Motor Driving Circuit 4.1.4 GPS Unit 4.1.5 Steering Wheel Sensors 4.1.6 Proximity Sensors 4.1.7 Wireless Communication 4.1.8 Base Station (PC) 4.1.9 Summary 4.2 VEHICLE DESIGN 4.2.1 Chassis 4.2.2 Drive train 4.2.3 Steering 4.3 MOTOR CONTROL CIRCUIT DESIGN 4.3.1 DC Motor Control Circuit 4.3.2 Stepper Motor Control Circuit 4.3.3 Testing and Analysis 4.4 VOLTAGE REGULATOR BOARD TO WIPORT POWER SUPPLY 4.4.1 Board Design 4.4.2 Testing Results 4.5 WIPORT AND ROUTER 4.6 MICROPROCESSOR 4.6.1 68HC11 Board Design 4.6.2 68HC11 Control Program 4.7 SENSORS 4.7.1 Steering Sensors 4.7.2 Collision Sensors 4.8 PCB DESIGN 4.8.1 PCB Overview 4.8.2 PCB Troubleshoot 4.9 PC INTERFACE TO REMOTE VEHICLE (PIRV) 4.9.1 Data Server 4.9.2 GUI Design 4.10 PC CONTROL PROGRAM 4.10.1 P Controller 4.11 OVERALL RESULTS 5 ASSESSMENT AND ANALYSIS 5.1 RECOMMENDED IMPROVEMENT 5.2 COST ASSESSMENT 5.2.1 Mission Critical Parts 5.2.2 Implementation Specific Parts 6 7 8 9 CONCLUSION SPECIAL THANKS REFERENCE APPENDIX 6 7 8 9 9 9 9 9 9 10 10 10 10 10 11 11 11 12 14 14 16 17 18 18 19 19 20 20 22 24 24 26 28 28 28 29 29 29 30 30 34 35 35 36 36 36 37 38 39 40

Table of Figures
FIGURE 1. BLOCK DIAGRAM ILLUSTRATING THE FUNCTION BLOCKS OF THE GPS ROBOT ........................................9 FIGURE 2 EARLY CONCEPT MODELS .......................................................................................................................11 FIGURE 3. DRIVE TRAIN SHOWING PULLEYS, TIMING BELT AND PULLEY MOUNTS ..................................................12 FIGURE 4. THE THREE CALIBRATION SENSORS (CENTRE, SEEN FROM ABOVE).........................................................13 FIGURE 5. STEERING ASSEMBLY (SEEN DURING CONSTRUCTION) ...........................................................................13 FIGURE 6. DC MOTOR CONTROL CIRCUIT SCHEMATICS. BASED ON THE DUAL-H-BRIDGE CIRCUIT FROM THE L298 DATASHEET ...................................................................................................................................................14 FIGURE 7. STEPPER MOTOR CONTROL CIRCUIT......................................................................................................16 FIGURE 8. OUTPUT WAVEFORMS OF STEPPER MOTOR DRIVING CIRCUIT RECORDED WITH FLUKEVIEW.................17 FIGURE 9. CIRCUIT SCHEMATICS FOR 3.3V VOLTAGE REGULATOR BOARD ...........................................................18 FIGURE 10. VOLTAGE REGULATOR PERFORMANCE WITH VARYING INPUT VOLTAGE .............................................19 FIGURE 11. 68HC11 MOTOROLA MICROPROCESSOR CIRCUIT SCHEMATICS ...........................................................20 FIGURE 12. 68HC11 MOTOROLA MICROPROCESSOR PIN CONNECTION DIAGRAM ..................................................21 FIGURE 13. 68HC11 CONTROL PROGRAM ARCHITECTURE ......................................................................................22 FIGURE 14. ORIGINAL STEERING SENSOR DESIGN SCHEMATICS ............................................................................25 FIGURE 15. ILLUSTRATION OF IMPROVED STEERING SENSORS ................................................................................26 FIGURE 16. PROXIMITY SENSOR OUTPUT ...............................................................................................................27 FIGURE 17. SENSOR PERFORMANCE .................................................................ERROR! BOOKMARK NOT DEFINED. FIGURE 18. GUI SAMPLE SCREEN ...........................................................................................................................30 FIGURE 19. PC FLOW CHART .................................................................................................................................33

List of Tables
TABLE 1. LOGIC INPUTS AND THEIR CORRESPONDING FUNCTIONS ..........................................................................14 TABLE 2. DC MOTOR SPEED WITH VARIOUS INPUT VOLTAGE ...............................................................................15 TABLE 3. CLOCK FREQUENCY WITH VARIOUS RESISTANCE ...................................................................................17 TABLE 4. ORIGINAL STEERING SENSOR STATUS AND THEIR CORRESPONDING WHEEL POSITIONS ...........................25 TABLE 5. IMPROVED DESIGN OF STEERING SENSOR ................................................................................................26 TABLE 6. COMPONENTS CRITICAL TO THE PURPOSE OF THE PROJECT......................................................................36 TABLE 7. COMPONENTS USED FOR CHOSEN DESIGN IMPLEMENTATION...................................................................36 TABLE 1. DC MOTOR CHARACTERISTICS ................................................................................................................40 TABLE 1. STEPPER MOTOR CHARACTERISTICS ........................................................................................................40 TABLE 1. STEPPER MOTOR PIN-OUT ........................................................................................................................40

1 Introduction
The goal of this project is to design and develop a logical robotic vehicle which has the ability to receive commands and move in the appropriate direction without any collisions. The robot should have the ability to avoid obstacles that may be in the way while it is traversing between a set of predefined waypoints on relatively smooth ground and arrive at its final destination. The vehicles physical motion is controlled by a DC motor to move forward and back and a stepper motor which controls the steering from left to right. The signals used to activate both motors are received by an onboard processor that takes into account the range of steering, obstacles and steering calibration before its sends data to the mechanical devices. The microprocessor obtains data from a logical pc program that calculates the direction the vehicle must travel in order to reach the various waypoints using GPS technology and a control algorithm. This report explains the strategy used in implementing the various different communication mediums as well as the hardware used to communicate data between systems. It also covers various mechanical and electrical design specifications which are crucial to the operation of the system.

2 Project Background
GPS technology has evolved quickly over the years. What seemed impossible at its outset can now fit in a shirt pocket. GPS technology has become accurate enough to pinpoint ones location to within three meters or less given the proper environment. With affordable receivers and free signal services, GPS based applications are worth exploring. An inexpensive GPS-controlled vehicle would serve as a stepping stone for a variety of commercial applications, such as fleet management, vehicle tracking and remote navigation. With the addition of an 802.11b wireless interface, the vehicle could be operated remotely from anywhere in the world.

3 Design Requirements and Goals

To declare the vehicle a complete success, it must be able to traverse the waypoint path across a smooth surface and stop within 3-5 meters of its destination. The vehicle should not require human intervention unless the environment falls outside of the physical capabilities of the vehicles hardware. The vehicle must also be controlled wirelessly and operate for long enough to reach its destination and make a return trip.

4 Results
4.1 Project Overview

Figure 1. Block diagram illustrating the function blocks of the GPS Robot

4.1.1 Motorola 68HC11 Microprocessor

Microprocessor 68HC11 is the central piece of the GPS Robot. It communicates with PC through WiPort and Router, controls motor circuits to turn the motors on and off, and accepts sensor readings to determine the wheel position and detect objects.
4.1.2 DC Motor Driving Circuit

DC Motor Driving Circuit switches driving motor on and off and ensures that there is enough current to run the motor.
4.1.3 Stepping Motor Driving Circuit

Stepping Motor Circuit manages to send a continuous set of pulses to activate the stepper motor.
4.1.4 GPS Unit

GPS unit is to measure the navigation position based on Global Positioning System. GPS unit also outputs industrial standard NMEA sentences for navigation.

4.1.5 Steering Wheel Sensors

Steering Wheels Sensors detect the current position of the front wheels and determine the orientation of the vehicle. The output signals are fed back to microprocessor for process.
4.1.6 Proximity Sensors

Proximity Sensors identify a nearby object and trigger a voltage level based on the distance from the object. The voltage is converted to digital format and registered in the microprocessor for process.
4.1.7 Wireless Communication

WiPort serves as a communication hub to exchange data between the microprocessor, PC, and GPS. Router serves a gateway for Base Station (PC) to communicate with WiPort onboard the vehicle.
4.1.8 Base Station (PC)

Base Station is a PC based program to receive GPS navigation data through WiFi and output direction commands back to vehicle to navigate.
4.1.9 Summary

At the time of this writing the robot vehicle has been designed and developed. Individual components of the robot have been tested and perform in a manner suitable for operation. These components include: Mechanical design The metal and design used to create the robot has the strength needed to uphold all onboard devices while allowing the vehicle to move in a sturdy and stable manner. Microprocessor/motor interface - Communication between the DC motor, stepper motor and microprocessor have been tested. The microprocessor is effectively sending data to the two motors controlling the motion of the vehicle in a timely fashion with very small delay between receiving the direction data and implementing the physical motion based in this information. PC program/GPS receiving/microprocessor interface Communication between the GPS receiver and the PC program has been tested. The WiPort used as the communication medium between these three functional units works effectively. By using a WiPort as the communicating device, we eliminate many issues involved in wireless communication such as lost or corrupt data. Overall the robot is responding effectively to direction commands and takes into account obstacles in its path while moving between waypoints. There are some areas such as the microprocessor algorithm that could be enhanced to provide smoother transitions while adjusting the steering based on obstacles sensors, steering calibration and receiving commands.

10

4.2 Vehicle Design

4.2.1 Chassis

The mobile platform is a 4-wheeled vehicle powered by a 12-volt DC gear motor. The vehicle chassis is made from 1/8 aluminium extrusion providing an extremely rigid base to which a number of electronic devices will be secured. The chassis material was scavenged from scrap metal, the inline-skate wheels were found in the back-alley, and the circuit housing was recycled from an old aluminium shelf, making the vehicle extremely cost effective. The original design was modeled to scale in 3D Studio MAX, enabling us to visualize and correct any design flaws before they were built. Since then the design has not changed drastically, the most major changes being a modified mount for both the DC motor and the stepper motor.

Figure 2 Early Concept models

4.2.2 Drive train

Initially we planned to use a 24V DC motor to drive the vehicle but would have required the series connection of two 12V batteries. The decision to use a smaller 12V motor meant that we could power it directly from one battery, reducing the weight of the vehicle and increasing the space available to place other components. The entire drive train is detachable as a single unit and can be mounted either forwards or backwards on the vehicle chassis. The bracket was designed in AutoCAD and the image pasted directly onto the metal sheet. This enabled us to quickly mark and punch the appropriate holes while still maintaining the accuracy needed to create two identical brackets. The bracket was fashioned with a slotted mount for the motor to allow the timing belt to be tightened or loosened as needed. The belt was left intentionally slack so as not to snap, if the vehicle collided with an object. Slotted pulleys are fastened to the rear axle with set screws allowing the drive motor to transfer power to the wheels using a small rubber timing belt. Inline skate wheels were used because they came pre-fitted with ball bearings. Though this was an advantage on the front steering wheels, washers had to be used to bypass the bearings and transfer power directly to the rubber wheel itself. We lathed the pulley mounts and secured them to the shafts with screws, allowing power to be transferred from the DC motor to the rear axle by the timing belt. The timing belt is 202mm in circumference and has 71 teeth. It transfers power from the smaller 15-tooth pulley to the larger 11

32-tooth pulley, reducing the rotational speed of the wheels by over one-half. The DC motor turns at 152 RPM, geared down internally at a ratio of 50:1. This produces a final wheel torque of 33.4 kgcm.

Figure 3. Drive train showing pulleys, timing belt and pulley mounts

4.2.3 Steering

Front-wheel Steering is achieved through a snail-gear system that provides a large amount of torque and extremely precise adjustment. The snail-gear is made from a threaded steel rod that drives a slotted metal arm attached to the wheels. As the snail gear turns, the slotted arm is forced either left or right, depending on the direction of rotation. The stepper motor, an EM-217, was taken from an old Epson printer along with sensors that allow us to calibrate the steering. The motor has a step size of 1.8. The snail gear has 20 turns per inch. The steering has a maximum travel of 2. The wheels have a maximum turning angle of 40 in either direction. The maximum turning speed can be roughly calculated using Equation 1. Since we use an external pulse generator with an adjustable setting, the steering speed can be manually adjusted.
second 1 pulse

1 step 1.8 shaft turn

360 shaft turn turn

20 turns inch travel

2 inches travel full travel

1 full travel 80 wheel angle

x pulses

step

Equation 1 Turning velocity

To ensure the vehicle does not accrue steering position error, three infrared sensors monitor the position of the wheels at all times. By detecting marks on a disc attached to the two wheel pivots, the extreme right, extreme left and centre position of the wheels are always known and can be used by the 68HC11 control program.

12

Figure 4. The three calibration sensors (centre, seen from above)

Figure 5. Steering assembly (seen during construction)

13

4.3 Motor Control Circuit Design

4.3.1 DC Motor Control Circuit

Our original DC motor controller was an H-Bridge design built from discrete components. The circuit used PN2222A transistors to control TIP127 and TIP122 Darlington transistors. However, in the tests with the DC motor, we found that PN2222A transistors became extremely hot. This phenomenon was realized after a new DC motor controller board that used an L298N dual H-bridge controller was created and was therefore never fully investigated.
J2

+12V Power

F1 2.5A + R5 1k U2 D9 78L05 LED2 IN OUT +

COM

C4 35uF

DVDD 5V +V

D2 DIODE M1

D3 DIODE

C2 330nF

R3 470

C1 100nF

R7 D4 1k DIODE

D10 LED2

D5 DIODE U1 L298N

put C1 close to 7805

D11 LED2 J3
A Enable B

J4
P15 P14 P13 P12 P11 P10 P9 P1 P2 P3 P4 P5 P6 P7 P8

U3A U3B U3C R2 470 R4 470 D8 LED2 D6 LED2 D7 LED2 R1 1

C3 100nF

put C3 close to l298

Figure 6. DC motor control circuit schematics. Based on the dual-H-bridge circuit from the L298 datasheet

The redesigned DC motor control circuit is able to supply up to 2A current for one bridge alone and power dissipation up to 25W. Input logic is shown in Table 1. Ven H H H L Inputs A H L H L X Function B L H H L X Forward Reverse Fast Motor Stop Free Running Motor Stop
Table 1. Logic inputs and their corresponding functions

H High Voltage L Low Voltage X Dont Care Condition

14

In addition to input A and B, which control the forward and reverse motion of the motor, an enable signal is needed to operate the circuit. To avoid modifying the control code on the microprocessor, we decided to pull the enable pin high on the circuit so that no additional output from 68HC11 is needed. As the truth table shows, the motor can be stopped either with input A and B both high or both low. L298N requires a separate logic power supply with typical voltage at 5V. In order to stabilize the chip performance, a 5V voltage regulator by LM7805 was used to supply this fixed voltage level. The diodes are used for fast recovery current recovery when changing motor directions. C3, a 100nF non-inductive capacitor was placed closed to the controller in order to maintain constant supply voltage as recommended in the device application notes. Voltage (V) 2 3 5 7 12 Current (A) 0.87 0.58 0.35 0.25 0.14 Rotation (rot/30s) 5.5 8.75 14.75 21.25 36.5 Speed (cm/s) 4.38 6.96 11.74 16.91 29.04

Table 2. DC Motor Speed with Various Input Voltage

15

4.3.2 Stepper Motor Control Circuit

DVDD 5V +V

D3 J3 1N4005 U4 78M05
1 IN OUT 3 2

XORcap 100nF

JKcap 100nF

ANDcap 100nF

OSCcap1 100nF

COM

C1 330uF

R2 400 D1 Power On S2

S1

12

Ext Clk Input A Input B

J1 U3B
5 4

R4 100

R3 R10 47k 47k

U2A

Q1 D IRFD120 G S

J2

U1D
13 11 12 9 8 10

U1C

R _ 11 K Q 14 13 CP 10 J Q 15 S 9

U3A
1 3 2

R5 100

Q2 IRFD120

Output 1 2 3 4

U2B U3C
8 10 9

5K 3 CP 6J

U1A
1 3 2

5 4 6

U1B

R _ Q 2 Q1 S

R6 100

Q3 IRFD120

U3D
12 11 13

R7 100

Q4 IRFD120

J4 J5

R8 400 U5A
1 3 2

FreqAdj 10k 40%

D2 Clock

Clock generator circuit

U5C
8 10 9

U5B R9 100
5 4 6

U5D
12 11 13

C2 1uF

Figure 7. Stepper Motor Control Circuit

The stepper motor control circuit is fed by three external signal inputs, clock signal, input A and B for motor control. TTL Input signals go through several logic gates and output signals are obtained at NAND gates. IRFD120 MOSFETs were put in place to amplify the output signals to drive the stepper motor. The circuit features an internal clock circuit and an external clock input connector. The circuit was able to generate a clock pulse with frequency defined by the adjustable resistor (see Table3). Alternatively, the circuit can accept an external source of clock signal, such as a pulse from 68HC11 microprocessor. Such a scheme facilitates the microprocessor to count the pulses and control the steering wheel turning angles. Figure 8 shows a waveform diagram of input and output signals, as well as clock pulse.

Figure 8. Output waveforms of Stepper Motor Driving Circuit recorded with Flukeview

4.3.3 Testing and Analysis

Internal clock generator circuit was tested by adjusting variable resistor. The clock frequency determines the turning speed of front wheels. The actual clock frequency was collaborated with 68HC11 program to achieve a desirable speed. Table 3 shows the testing results of the clock circuit. Adjustable Resistor (k) 2.243 1.955 1.661 1.028 0.627 0.262 Clock Frequency (kHz) 0.4334 0.4947 0.5776 0.8614 1.3822 2.5472
Table 3. Clock Frequency with Various Resistance

4.4 Voltage Regulator Board to WiPort power supply

4.4.1 Board Design
TP3 U1 LM2676-ADJ J1
1

Power 12V

F1 FUSE
2

D1 1N4005

P1 P2 P3 P4

P7 P6 P5

J6

Cb 10nF

TP4 Rfb2 20k 40% R2 1k Cf 100nF Rfb1 2.490k Ron 1k TP1

Adjustable resistor

Power plugs for other boards

J2 J7

Cin 1uF Cinx 100nF D7 ZENER

L1 33uH

J5

Output
J4 Cout 1uF TP2

J3

Figure 9. Circuit Schematics for 3.3V Voltage Regulator Board

LM2676 is an adjustable DC voltage step down IC chip with input voltage range 8V to 40V. The circuit output was to supply voltage and current to the Wiport, which requires 3.3V power and peak current of 460mA. The circuit was designed by National Instrument WEBENCH program in accordance with the power requirements of WiPort. LM2676-ADJ is one of LM2676 voltage regulator series with adjustable output voltage. Desired output voltage was achieved by tuning the adjustable resistor at Pin5. Taking consideration of current protection diode on WiPort circuit board, we fine-tuned the regulator circuit to output a voltage level of 4.4V. It comes from the fact that 1N4005 diode forward voltage drop is 1.1V. Thus we were able to achieve 3.3V power supply to WiPort.

18

4.4.2 Testing Results

Figure 10 shows the test result of the voltage regulator circuit with various input voltage levels. The minimum input voltage for LM2676 is 8V. The performance diagram shows the regulator circuit is able to maintain 4.4V level corresponding to the input range of 8 to 16 volts. Above 16V, output voltage level tends to climb up proportionally to the input voltage level.
6 5.8 5.6 Outpout Voltage / V 5.4 5.2 5 4.8 4.6 4.4 4.2 8 10 12 14 16 Input Voltage / V 18 20

Figure 10. Voltage Regulator Performance with varying input voltage

4.5 WiPort and Router The Lantronix WiPort was chosen as the method of communication because it employs a standardized communication protocol (802.11b), has two serial connections, is simple to use, and has lower cost than similar devices. The WiPort enables communication with two attached serial ports via an IP address and port number. This allowed us to easily transmit and receive data from the 68HC11 without having to develop a proprietary protocol or wireless transmitter. The 802.11b specification also takes care of retransmission in the event of data loss, thereby ensuring the link between the vehicle and the base-station is invisible to the onboard processor. Although the WiPort allows for simple communication, it is not a point-to-point connection and must connect to a router in order to network with other devices. This forced us to use a wireless router at the base-station but does allow the PC to communicate with the vehicle without the need for a WiFi connection of its own. The WiPort connects to the wireless routers network on Channel 1 so as to avoid overlapping signals with neighbouring wireless networks. The WiPort has a static IP and is set to communicate with the GPS on port 10001 at 4800 Baud, as per the NMEA standard. The 68HC11 is connected to the WiPort at 9600 Baud on port 10002. Data packing is turned off in order to send data as soon as it is received instead of grouping it into chunks.

19

4.6 Microprocessor
4.6.1 68HC11 Board Design
MAX232 U1
P1 U9 P16 P2 P15 MAX232 P3 P14 P4 P13 P5 P12 P6 P11 P7 P10 P8 C18 P9

R11 120 R12 120 J1

J11

C17 22uF

C12 22uF

+ C16 22uF

22uF +

J9

J10

D3 LED2 R5 270 J8 R3 10k

D4 LED2 R1 270 D1 Power On R10 5k

J12 U8 78M05
OUT IN

J7

J4 J6 R9 10k

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

U7 68HC11 48
47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25

D2 1N4005 C1 C15 100nF 100uF

J3

R2 10k

R7 R8 10k 10k C14 10nF

2

C10 100uF

COM

J5

U5 DS1233-M C13 22pf XTAL1 ECS-80-20-1

R6 1M C11 22pf

S3

10k R4

J2

Figure 11. 68HC11 Motorola Microprocessor circuit Schematics

The Motorola 68HC11 was chosen to be the microprocessor in our project because we had experience with the chip from previous years and are familiar with the interface and Buffalo program. Furthermore, 68HC11 is widely used in the industry to perform various tasks and all external parts for 68HC11 circuitry were available from previous projects so that we were able to reduce the costs. The final deciding factor was that the group leader had a development board already built from a previous course which would allow for immediate testing of the control program. An external crystal supplies the 68HC11 chip with a clock pulse at 8MHz. MAX232 converts TTL signals to serial signals through DB9 to WiPort serial connector. DS1233-M was to monitor the microprocessor supply voltage. It triggers a reset signal when the voltage reaches an out-of-tolerance threshold voltage. When the voltage falls back to the normal range, the reset signal stays on for about 350ms to allow the processor to stabilize. MAX232 provides a basic voltage protection to the microprocessor chip. We encountered a problem with the buffalo program, which was not able to recognize a space character and we were not able to enter commands to communicate with the microprocessor. During troubleshooting, we discovered that 22F capacitor was misplaced to pin15 instead of pin6 on MAX232. After correcting the problem, 68HC11 was able to accept commands through a serial port from a computer terminal program. 20

To control the movement of the GPS robot, an embedded microprocessor is employed to instruct the robot appropriately. The main function of the microprocessor is to receive data from both port server and IR sensors, process the data and output commands to control stepper motor and DC motor, ultimately controlling the direction and movement of the GPS robot. The 68HC11 receives inputs and sends signals as illustrated in Figure 9.

Proximity Sensor

18 Port E 1 19 Port E 2

Port B 1 15 Port B 2 14

Stepping Motor Driving Circuit

Steering Sensor

31 Port C 0 32 Port C 1 35 Port C 4

Port B 3 13 Port B 4 12

DC Motor Driving Circuit

Microcontroller Motorola 68HC11

Port D 0 42 WiPort

Port D 1 43

Figure 12. 68HC11 Motorola Microprocessor pin connection diagram

The microprocessor program is made of five major components: calibration, checking serial input, checking IR sensors, and sending the output. Utilizing the Buffalo Monitor program already resident in the processor, we can call a number of pre-programmed commands that allow for simple serial communication. Before receiving any data, the vehicle calibrates its steering but does not loop back to this function once the main loop has begun. Once the main loop instructions are completed, the program will repeats the process beginning at checking for serial input. The sequence diagram is illustrated in Figure 10.

21

4.6.2 68HC11 Control Program

Figure 13. 68HC11 control program architecture

When the GPS robot is first turned on, the microprocessor goes through a series of steps in order to calibrate the steering of the vehicle. These steps not only ensure that the wheels are aligned and straight, it measures the vehicles turning range. With this information the control program can calculate the number of times through the main program loop it must complete in order to move the wheels to the desired location. Calibration begins by turning the stepper motor to left, once the left sensor is triggered, the pulse count is reset. The wheels then turn right and the pulse count is incremented each loop. When the next sensor is triggered, the pulse count is stored as a two-byte steering range and is used in a number of places throughout the control program. At this point the vehicle is ready to operate. During testing we experienced some difficulty sending Buffalo numbers greater than 127, but a later discovery suggests that it was our testing method that was causing the problem. Nevertheless, we map the far left wheel position to $00 hex and the far right wheel position to $7F. Using the original calibration sensor setup we experienced synchronization problems with the centre position. To detect the centre wheel position the program must monitor two sensors. However, the two sensors are not triggered at exactly the same time because the markers on the calibration discs are not placed exactly alike nor are they precisely the same width. This caused the control program to incorrectly interpret the position data occasionally despite our efforts to minimize the effect with software. To overcome this problem the program checks the sensors twice, once before moving the wheels and once after. This approach efficiently reduced the 22

occurrence of incorrect position data but did not eliminate it entirely until we added a third sensor, see 4.7.1 Steering Sensors. Finally, we store the steer range to a memory address for access later. The steer range is then divided by a decimal number by the range of GPS steering data (128) to calculate pulses per bit. At end of calibration routine we have achieved three tasks: centered and straightened the wheels, found the steer range, and found the pulses per bit based on the steer range. Once the calibration routine is complete, the main loop of the program begins and. There are two main components involved in controlling the GPS robots movement. The first component controls the forward and backward motion of the vehicle and the second component controls its turning. In order to direct the robot to its final destination both of these components must work together to enable the robot to move in the appropriate direction without any collision with surroundings. In this program we use four commands from PC program. They are manual enable, auto enable, GPS steering and DC motor control and they are labelled as 1, 2, 3, and 4 respectively. PC program will send 1 or 2 at beginning to specify the mode of the robot. With manual enabled, the GPS robot will ignore the collision sensors allowing for full control from the PC. With auto enabled, the robot will take both GPS steering value and IR sensor value into account, avoiding objects as it drives to its destination. The checking serial input starts with a 68HC11 built-in command: JSR $FFAC, which will load the accumulator A with serial input. The serial input is our expected command from PC program. The program uses the op-code received as an offset into a jump table of addresses to subroutines. Because the address is a two byte value, subtract 1 from the op-code value, double the value by bit shifting left, and then add the value to the base location of the jump table. There are four possible outcomes from the jump table. If a 1 is received, it indicates a manual enable and the jump table will direct the program execution to a subroutine called SETMANUAL that sets the MANUALENABLE byte in the memory to $01. If a 2 is received from the serial port, the jump table will direct the program execution to a subroutine called SETAUTO that clears the MANUALENABLE byte in the memory by setting it to $00. A 3 indicates a GPS steering command, and will cause the control program to wait for the reception of another byte indicating the desired wheel position and store it in GPSDATA. This waiting is dangerous because the control program does nothing else until it receives a second byte. A loop counter that would break the program from this loop after a set amount of time was planned but not implemented due to time constraints. If 4 is received, the program will wait for a second byte indicating the desired input to the DC motor control circuit. After checking for serial input, the program reads in the collision sensor data. The input coming from these sensors output an analog voltage indicating the distance to the sensed object and must be converted to a digital signal before the microprocessor can analyze the data. This is achieved using the 68HC11s onboard Analog-to-Digital converter which is able to multiplex up to 4 inputs. Because of the Buffalo Monitors debug requirements, the high voltage reference pin is already set to 5V, and the low voltage reference is set to 0V. Therefore the collision sensors maximum voltage of 2.5V produces a digital value of $7F. The analog signals on the 2 different pins on PORT E are sampled at specific intervals and the values are stored in the memory. These values are constantly used in the final steering algorithm and therefore adjust the steering direction continuously, depending on the surrounding conditions. 23

To carry out this operation, we first set the condition Y register to the OPTION and ADCTL registers, set bit ADPU in OPTION register to power up A/D system, clear CSE$L in OPTION in order to use the E-clock. Then we load the status register ADCTL to check if the conversion is complete. Once CCF is equal to 1, indicating the completion of the conversion, the control program reads the results of the A/D conversion from PORT E. Since the sensors have a no object detected value of about $10, we set a low sensor threshold of $15 to ignore all insignificant data. The objective of weight function is to calculate final steering position based on both manual and auto modes. We first check whether the robot is set in manual mode or auto mode by loading the MANUALENABLE byte. If the MANUALENABLE byte has a value above $00, it will take the GPSDATA as final steering value, otherwise we will follow the algorithm to determine the robots action to avoid collision with surrounding objects. We set two threshold values, the high threshold IRHITHRESHOLD and the low threshold IRLOWTHRESHOLD. If either sensor input is between the two thresholds, the control program finds which is greater and steers in the direction opposite to that sensor. If both sensors are above the high threshold indicating the vehicle is very close to an obstacle immediately in its path, the control program performs an emergency stop by shorting the DC motor terminals and putting the vehicle into manual mode. When we determine the final steering position (one byte value between $00 and $7F), we can map it to a position in our total steering range by multiplying it by the PULSESPERBIT value obtained from the calibration routine. The steering routine follows the six steps: checking the calibration sensor, if the calibration sensors are triggered, we set the CALIBDETECT value to $FF; determining the direction of turning such as left or right, we compare the weighted steering data and make a comparison to the centre position of the wheels, allowing us to jump to left turn or right turn code; turning the stepper motor to left and right followed by a delay of a standard time unit; checking sensors again in case the stepper motor moved the shaft out of range; updating our current position for next instruction. The original 8 motor control routines were reduced to a single function is used to control the motor control output using masks to set specific bits high or low on PORT B. Pin 0 and 1 are used to govern the behaviour of DC motor, and pin 2 and 3 are used to govern the behaviour of stepper motor. Because the general operation of setting specific bits is the same for both DC motor and stepper motor, we used a generalized method to set the bits called SETPORTB. We first load accumulator A with stepper motor mask (%11110011) or DC motor mask (%11111100) and load accumulator B with the mask of the bits should be unset. We use logic function AND for Accumulator A and PORT B to set pin 0 and pin 1 low for DC motor or pin 2 and 3 low for stepper motor. The result is output on PORT B. Then we use logic function OR for accumulator B and PORT B to set specific bits high depending on the operation. Once the steering routine is completed, the program will return to the address where the program will begin to process another round of instruction from serial port. 4.7 Sensors
4.7.1 Steering Sensors

The original steering sensor layout used two sensors placed near the front right wheel and monitored a clear calibration disc with two markers on it. As the turned from side to side, the 24

disc moved with them, allowing the sensors to detect the wheel position at three points, centre, full right, and full left. The steering sensors are through beam sensors that activate with a TTL high when they are blocked by a marker. A schematic diagram of steering sensors, markers, and the front wheel position is shown in Figure 14. Figure 5 provides a full description of sensor status and front wheel positions.

Metal Disc

Markers

Right-front wheel 1

Steering Sensors

Figure 14. Original Steering Sensor Design Schematics

Through Beam Sensor 1 Sensor 2 Clear Blocked Blocked Clear Blocked Blocked Clear Clear

Sensor Output Voltage (V) Sensor 1 Sensor 2 0 4.9 4.9 0 4.9 4.9 0 0

Wheel Position Full Left Full Right Centre Undetermined

Table 4. Original Steering Sensor status and their corresponding wheel positions

This method of wheel position controlling became problematic when programming the 68HC11. As Table 4 indicates, centre wheel position requires both sensors to be blocked. However, it is not possible for both sensors triggered at the exact same time and errors occurred that tricked the program into believing it was at a position other than centre. To overcome this we programmed the processor to wait for the wheels to finish moving after detecting a marker and check again to see if the sensors were triggered. If they were, their position data was accepted and the wheel position updated. The problem was adjusting the wait state properly to allow the second sensor to trip while still triggering the first object sensor. Various adjustments to the program were made to correct this, but none variable programming solution was found. The problem has to be solved by adding another steering sensor to help simplify the steering and increase accuracy. The third sensor was mounted to the left side to avoid waiting to check for the second sensor to trip. Instead of monitoring the position of two markers per disc, only one marker is used per disc and are placed in such a way that only one sensor can be triggered at any given wheel position. A diagram of the sensors, makers, and corresponding wheel positions is provided in Figure 15.

25

Wheel Straight Sensors 1 L e f t 2 3 R i g h t Right Wheel

Wheel Full Left

R

i g h t

Markers Metal Plate

Wheel Full Right

L e f

Table 5 provides sensor status and the related wheel positions for the improved design. Sensor 1 Blocked Clear Clear Clear Through-Beam Sensor 2 Clear Blocked Clear Clear Sensor 3 Clear Clear Blocked Clear Sensor Output Voltage (V) Wheel Position Sensor 1 Sensor 2 Sensor 3 4.9 0 0 Full Left 0 4.9 0 Full Left 0 0 4.9 Centre/Straight 0 0 0 Undetermined
Table 5. Improved design of steering sensor

The collision sensors are analog devices and we took advantage of embedded analog-to-digital converter (ADC) on 68HC11 to digitize sensor output voltages. The sensors were mounted at the front of the vehicle to detect objects in the vicinity of 10 to 80cm. We chose Sharp GP2D12 because of its low cost and reasonable performance. The sensors were run at 5V and internal driver circuit outputs a voltage proportional to the distance to the object. The outputs of the sensors are connected to 68HC11 ADC pins. Figure 16 shows the output voltage measurements with an object in front of the sensor from 5-80cm. The test was conducted indoors with fluorescent lights on.

R i g h t

Figure 15. Illustration of improved steering sensors

4.7.2 Collision Sensors

26

2.4 2.2 2 1.8 Output Voltage / V 1.6 1.4 1.2 1 0.8 0.6 0.4

10

20

30 40 50 Distance from sensor / cm

60

70

80

Figure 16. Proximity Sensor Output

As shown in Figure 16, the sensors output voltage dips within a distance of 10cm. This results the vehicles inability to identify an object within 10cm or may not react fast enough to manoeuvre.

27

PCB Design
4.7.3 PCB Overview

The Printed Circuit Boards (PCBs) were designed with TraxMaker 2000. The boards were designed by exporting PCB netlists from CircuitMaker 2000. The tracks, vias, and holes were auto-routed by TraxMaker in accordance with the specifications from Alberta Printed Circuitboards. We designed four circuit boards, DC motor control circuit, stepper motor control circuit, 68HC11 microprocessor circuit, and 3.3V DC voltage regulator circuit.
4.7.4 PCB Troubleshoot

Though we checked each PCB before submission, we found a number of errors upon receiving the actual boards. Each of the final boards was modified to correct errors by cutting and rerouting traces. The 68HC11 control board served as a lesson for good design practice. An error in the circuit diagram used by the designer prior to this course was corrected in his final board but not updated on the circuit diagram. This error was then reproduced 2 years later, and took a nights work to find that the connection between MODB and pin 17 on the 68HC11 was not being pulled high, and that the MAX232 chip had pin 6 and pin 15 connections reversed. The effects of this were not immediately obvious while running the 68HC11 at 9600 Baud; however at slower speeds the MAX232 was unable to maintain the voltage required to output a proper waveform because the pulses were longer. This only became apparent when we lowered the 68HC11 Baud rate to 300 BPS to program it and the serial transmission became garbled. Additionally, as we added sensors to the vehicle, we powered them from the 68HC11 boards 5V supply. The LM7805 voltage regulator we used to power the board is rated at 1A, but requires a heat-sink to dissipate energy at a current load of anything over 60mA. With the heatsink attached, the package no longer becomes too hot to handle. The DC motor circuit was the most successful of our boards. The only modification to it was to make new holes to accept the large heat-sink we added because we had no footprint data and our measurements were off. Pin 15 on the L298 serves as a current sensor pin allowing motor current to be re-routed to an external current monitoring circuit. In our application pin 15 is the return connection to ground. Because of this, we designed the circuit 1 a resistor in series that would enable the addition of an external monitor circuit should we have need for one. However, during construction we accidentally placed a 1k resistor on pin 15 instead causing the voltage and current across the motor to drop to zero as soon as the motor was connected. This is to be expected as to draw the 200mA the motor requires under normal use, we would have needed a supply of 200V to drive it across the larger resistor The stepper motor controller had two errors, incorrect package information and an inadequate diode. After making the mistake of using a TO-92 package for the IRFD120 MOSFETs in the original board, on the second board we made sure to change the package type to DIP4. However, we neglected to change the pin designations to match the actual chip, resulting in a number of cut traces and rerouted signals. Using the accidental finger burn we realized the diode used to protect the circuit from reverse voltage was inadequate for situations in which the stepper motor became jammed. The current draw under these conditions approached the 1A limit of the 1N4005 rectifier diode we used and so it was replaced with a 400V, 3A diode from an old television set. 28

The voltage regulator board had only a single circuit error; a resistor was pulling the control pin on the LM2676 regulator chip low. This had the effect of shutting off the regulator and was corrected by pulling it high. The only other error on the board was the incorrect marking of capacitor values that caused a number of components to be connected to the wrong capacitors. This was corrected using the usual cut and re-route method. 4.8 PC Interface to Remote Vehicle (PIRV)
4.8.1 Data Server

The class extends Thread allowing it to operate independently of any other thread also keeping the GUI responsive. dataIn is the string in which received data is concatenated as it is read from the buffer. m classes sourceSocket is the socket which will be used to receive and transmit data. terminateFlag causes the dataServer to terminate at the next available opportunity. isDataReady takes an array of strings and searches string dataIn to see if they have been received, returning True if this is the case. get_readData returns a copy of dataIn and then clears the original. run is the overloaded member Thread class function. When it is executed run will continuously concatenate data received from sourceSocket in dataIn until terminateFlag is set, at which point the thread will terminate in an orderly fashion. set_Socket sets sourceSocket to the specified socket. set_terminate sets the terminateFlag to the specified value. set_sendData transmits the specified data out on sourceSocket. Two dataServer objects are instantiated in PIRV, one to manage communication with the GPS and the other for the 68HC11. This, coupled with the two serial ports on the Lantronix WiPort device allows simple bi-directional communication with both serial sources on the vehicle. The advantage of a bidirectional system over the original unidirectional system is that instructions from the PC are no longer best effort because an acknowledgement of reception can be transmitted back to the PC. This also means data can be sent to the GPS, allowing complete remote configuration of all onboard processors should the necessity arise.
4.8.2 GUI Design

The GUI class is instantiated by the main process and contains all the controls to set up communication with the vehicle and to manually control its motion. The data fields in the GUI are updated automatically whenever a field value is calculated. This is achieved using delegates to cause the GUI to update within its own thread of control, despite the call having originated in a separate thread. Though the GUI updating could have been simplified if we had raised our own events to indicate a field needed updating, no working examples of how to implement this in J# could be found in the time we allotted for the PC software development. Though not originally stated in the project outline, the GUI could also be used to dynamically set waypoints using a point-and-click method on a map overlay. The coordinates would then be transmitted to the GPS using the bidirectional link. Additionally, data gathered and processed by the 68HC11 could be sent back to the PC base-station for debugging.

29

Figure 17. GUI sample screen

4.9 PC Control Program

4.9.1 P Controller

The main functionality of the pc control program is to navigate the GPS Robot correctly on its path. It is constantly fed GPS data which is received by the data server and extracts the necessary values from it. It then converts the data to useable data such as strings or number to calculate the correct amount the GPS Robot should turn for optimal navigation. It then sends the data back to the data server and updates the GUI as necessary. Three subroutines are used to calculate the final navigation data for the robot: AimToWaypoint, AimToCorrect and AimToPath. Several functions had to be made to successfully implement the pc control program. A P Controller (proportional controller) was used to reduce errors in the control algorithm as well as the data errors that might be present. We had the option to implement a PID Controller but it seemed unnecessary for this project because the vehicle does not move very quickly. A simple error correcting algorithm seemed more than sufficient for our goal because our navigation was on a 2-dimension space. Several obstacles had to be overcome to make the pc control program to work in the desired way: accuracy of the GPS data, calculations for each subroutine and the weighting algorithm. Another obstacle which that faced some of the PC programming team was learning the J# language that was used in the communication proof of concept. Many changes were made during the course of the semester and important decisions had to be made from time to time. The data received from the data server was in a string of GPS data and the values within it had to be extracted and converted to useful data which can be used in calculations. Here we faced our first problem which was solved quite easily. The GPS sent data at a rate of 1Hz but did not always send the same number of lines due to the lag in the GPS itself and also the lag in the wireless signal. Before the data could be extracted, we had to make sure all the data we received was present and valid. Simple data checking function was then made to check all values that will 30

be used in the program to make sure the data was valid. To locate the correct data within the string, we counted the number of commas after the desired NMEA sentence was located. Once it passes the data check, it then extracts each data within the string to either a string or a double which can then be sued to calculate the output. All values used from the GPS data were globalized within the class for all functions to share. Here we faced our biggest problem for the pc control program. The accuracy of the GPS was very limited and the accuracy changed from time to time for the better or for the worse. Sometimes the GPS would output erratic data due to reduced satellite signal reception. To correct these errors we first decided to take in three GPS data and take the average of the three values we received. This did not completely fix the problem because the undesired data was still put into calculation in the average. After coming up with several other ways to implement the error correcting algorithm, it was decided that taking the median of the three values was the most accurate without getting more data from the GPS. Getting more than three GPS data to be used in the calculation was not an option because the constant movement of the robot, although the robot itself did not move very fast, made the most recent reading seem much more reliable than readings from older data. Median made it possible to eliminate the sometimes sporadic data the GPS sent. Having all the necessary data extracted from the GPS data string, three functions are called to do separate calculations to be weighted by a forth function. First of the three functions is called AimToWaypoint function. As the name implies, the main goal for this function is to make the GPS Robot face the destination. It does not take into account anything but the current bearing the GPS Robot is headed and the destination bearing from its location. When the GPS Robot is headed in a completely wrong direction, the output is given to make a full right or a full left turn. As the robot approaches the desired angle, the turning output is gradually reduced to make for a smooth turn toward the destination. The AimToCorrect is the second function of the three that does a calculation that will be weighed in the final output. When it was first created, it used the cross-track error given by the GPS unit. It was later noted that it was accurate within 0.01 nautical miles which was 18.53 meters. This was very inaccurate for the purpose of our project and therefore the cross-track error had to be calculated ourselves. Another function was created to calculate the cross-track error, which is the same as the distance from the track. Our DistanceToTrack function works by using the current and the destination location which are given in longitude and latitude and the bearing for each to calculate the distance 90 degrees from the path. The function uses a simple triangle law to calculate the distance and it improved our accuracy drastically. It was able to detect change in distance as little as 0.1853 meters. Since the GPS itself is only accurate up to 3 meters, our function will never be as accurate as it reads but it is still much more accurate than the previous method we used. Even though the cross-track error given by the GPS is not accurate, the turn to correct given by it seemed much more accurate. Turn to correct gave a value of R or L and it showed which way the GPS should turn to get back on track. We used the turn to correct and the distance to track to calculate the amount the GPS Robot should turn. It was an integration of a P Controller where the distance to track is directly proportional to the amount the robot should turn.

31

The last of the three functions is called AimToPath and its sole purpose is to aim the GPS Robot directly toward the track. This function was created to make sure the robot does not go backwards away from the waypoint during any part of the navigation. The bearing between waypoints is used to find the 90 degree angle toward the path. It takes a look at which way the GPS Robot is going and the desired angle, which is the 90 degree angle toward the path, and depending on the amount to turn, adjusts the output accordingly. The farther it needs to turn, the more it will turn. Finding which side of the path the robot is at was the greatest task for this function because the data we had at hand was very limited. We ended up using the GPS data which gave the direction to turn to correct the cross-track error. It was a simple solution to what seemed to be one of the more difficult tasks. The final function which combines all three of the subroutines to calculate the final output is called ApplyWeighting. This function calls all three functions and outputs the data each function returns to GUI. It then uses the three data to do proportional algorithm which primarily depend on the distance off track. Here, our main goal was to make sure the robot returns to its desired path as soon as possible when it is very far from the path. As the robot gets closer and closer to its path other factors such as the bearing to the waypoint starts to get weighed more in the calculation. When all three functions return similar values, no calculation is done and the output is the value all three functions agree to. The main function of the program calls the data server and gets three separate GPS data which will be used in the calculation. Here we ran into another problem where the CPU was used up during the loop to get more data when the data check failed. We implemented a sleep function that slept the thread for 100 ms before it tried to get more data from the data server. We also had to change the output to be in the range between 1 and 127 to accommodate the 68HC11 program. The main function also updates the GUI with the values used and calculated. Since the pc program runs on threads, the response of the system stays optimal during runtime.

32

Diagram shows the flow of data from the GPS input to the 68HC11 steering data output. Individual field data is extracted from the GPS string. Field data is then used at will by the Aim functions. The Aim functions output wheel positions which are then weighted and sent back to the Vehicle.

PC-Vehicle Communication

GPS Data String

Data Check

GPS Data String

Extrack Value

Data Fields

Cross-track Error Vehicle Orientation Bearing to Waypoint Track Orientation Etc...

Required Data Fields Required Data Fields Required Data Fields

AimToWaypoint

AimToCorrect

AimToTrack

Wheel Position

Wheel Position

Wheel Position

ApplyWeighting

Steering Opcode & Weighted Wheel Position

PC-Vehicle Communication

Figure 18. PC Flow Chart

33

4.10 Overall Results The vehicle design worked exactly as intended save for a few minor modifications to the steering. It was able to receive and carry out wireless commands from the PC and transmit GPS data back to the PC. The PC program receives data from the GPS and outputs steering values that aim the vehicle back on course. At the time of writing however, the PC program suffers from an update delay problem that will have to be rectified in order to provide updates fast enough for the vehicle to steer.

34

5 Assessment And Analysis

5.1 Recommended Improvement Though the vehicle is operational to within our expectations, there are a number of aspects that we would change in the next design iteration. One such change would be the collision sensors. The collision sensors have a range limited to 80cm, however, there is so much ambient interference that they are only useful starting at about 40cm, at which point it is almost too late to avoid an object directly in the vehicles path. Another improvement would be to replace the rubber timing belt on the DC motor with a metal chain. This would eliminate the possibility of the power transfer belt snapping but would also introduce a new problem. In the event of a collision, the DC motor would become stalled and would draw its stall current of 3.8A. In this case we would have to make use of the L298s current sense pin in order to shut down the motor automatically before it could damage the circuits. In addition to the current sense, we could also place physical collision sensors on the front and back as a last line of defence against collisions. These sensors would ensure that all actions necessary to prevent damage to the unit. Although the 68HC11 is more than powerful enough to control the vehicle, newer chips offer much more ROM that could have enabled us to control the vehicle entirely from the onboard processor itself. With out current chip we could have overwritten the Buffalo Monitor with more code; however it would be simpler to code given more room since a high-level language compiler could be used to generate the machine code instead of programming in assembly. Lastly, we would have liked to implement a time-to-live counter on the vehicle that would have turned off the motors should the vehicle lose contact with the base station. The vehicle would monitor the time since last reception and would shut down if the limit was exceeded. This would require the base-station to continuously send connection test signals to the vehicle, however we simply ran out of time and this was not implemented.

35

5.2 Cost Assessment

5.2.1 Mission Critical Parts

Item Garmin eTrex Basic GPS Total

Quantity 1

Unit Cost $110.00

Cost (all in cost) $123.70 $123.70

Table 6. Components critical to the purpose of the project

5.2.2 Implementation Specific Parts

Item 12V DC Motor GP2D12 Collision sensor Shaft Collars 71T Timing Belt Pulley 15T Pulley 32T LM 2676 OMRON EE-SJ3-D Wolfe GPS PC combo cable WiPort Development kit Total

Quantity 1 2 1 1 1 1 1 3 1 1

Unit Cost $29.95 $16.99 $2.65 $9.95 $3.95 $3.95 $5.56 $3.95 $34.95 $149.00

Cost (all in cost) $54.84 $38.74 $5.15 $12.45 $6.45 $6.45 $7.34 $14.51 $43.40 $149.00 $338.33

Table 7. Components used for chosen design implementation

36

6 Conclusion
The project was a difficult task for all involved. It required time management, technical knowledge, and the ability to perform on ones own. Through the course of the term we learned about working together in a team to produce a final product, a task that is more difficult than it would at first appear. However, in the end, we delivered most of what we set out to accomplish. It is unfortunate that at the time of this writing, the GPS navigation of the vehicle is not fully tested. However, all indicators suggest that the PC program works and will in fact be tested later today. The vehicle itself works exactly as specified in the original outline and exceeded our original design in its simplicity and robustness. As parting words from the team leader, this was the most intensive self directed project that I and many of our team members have been a part of. Though we encountered some problems with division of labour, fabrication of boards and generally dealing with the elusive reality factor K, we have all learned greatly from this experience and will be able to use this knowledge to avoid the pitfalls we encountered in the future challenges we face. Nicholas Jakobsen

37

7 Special Thanks
A number of people donated time and parts to make our project possible. We would like to recognize their contribution here. Ole Jakobsen the Trouble-shooter Extraordinaire Cam Bremner for the donating the L298 H-bridge Jesse at GPSCentral.ca for his help supplying us with a GPS device Michelle Miller at Lantronix for her help supplying us with a WiPort Tom de Rybel, professional pessimist/professional realist

8 Reference
1. National Instrument WEBENCH, March 16, 2006 http://webench.national.com/appinfo/webench/scripts/my_webench.cgi 2. PID Controller Algorithm in programming, March 20, 2006 http://www.jashaw.com/pid/code.htm 3. Motorola 68HC11 Microcontroller Datasheet, February 10, 2006 http://www.freescale.com/files/microcontrollers/doc/data_sheet/M68HC11E.pdf 4. Buffalo Monitor Program Instruction Sheet, February 10, 2006 http://www.technologicalarts.com/myfiles/data/buffalo.pdf 5. National LM2676 Switching Voltage Regulator Datasheet March 1, 2006 http://www.national.com/ds/LM/LM2676.pdf 6. STMicroelectronics High Switching Transistor 2N2222A Datasheet, February 4, 2006 http://www.st.com/stonline/products/literature/ds/9288.pdf 7. Fairchild Semiconductor 1N4005 General Purpose Rectifier Datasheet, February 4, 2006 http://www.fairchildsemi.com/ds/1N/1N4005.pdf 8. Fairchild Semiconductor LM7805 3-Terminal Positive Voltage Regulator Datasheet, March 10, 2006 http://www.fairchildsemi.com/ds/LM%2FLM7805.pdf 9. Fairchild Semiconductor Dual J-K Flip-Flop Datasheet, February 4, 2006 http://www.fairchildsemi.com/ds/CD/CD4027BC.pdf 10. Texas Instrument CMOS Quad Exclusive-OR Gate Datasheet, February 4, 2006 http://focus.ti.com/lit/ds/symlink/cd4030b.pdf 11. Fairchild Semiconductor Quad 2-Input NAND Schmitt Trigger Datasheet, February 4, 2006 http://www.fairchildsemi.com/ds/CD/CD4093BC.pdf 12. Garmin eTrex User Manual, February 4, 2006 http://www.garmin.com/manuals/eTrex_OwnersManual.pdf 13. Lantronix WiPort http://www.lantronix.com/device-networking/embedded-device-servers/wiport.html

39

9 Appendix
Manufacturer Part Number Description Voltage RPM Reduction Stall Torque Outside Diameter Weight Stall Torque Length (motor and gear) Length (shaft only) Diameter (motor and gear) Diameter (motor and gear) Diameter (shaft) Outside Diameter Current (at 12v no load) Current (at 12v locked shaft) Hsiang Neng HN-GH12-2413T DC-12V-152RPM 50:2 12vdc 152 50:1 231.5 oz-in (16.7 kg-cm) 37mm 7.15 oz 231.5 oz-in 2.33" (5.92 cm) 0.89" (2.26 cm) 1.45" (3.68 cm) 1.45" (3.68 cm) 6mm 37mm 145mA 3.8A
Table 8. DC motor characteristics

Manufacturer Part Number Description Series # of Models in Series Machine Type Size (mm) Step Size (deg) Best Accuracy (arcmin) Cont. Holding Torque (N-cm) Rated Current / Phase (A) Nominal Voltage (VDC)

Minebea Co, Ltd. Type: P/N: Em-217 17PM-K041-P2F 17PM-K 10 H N17 1.8 5.4 14.8 0.4...1.2 3.0...10.0
Table 9. Stepper motor characteristics

Common
Table 10. Stepper motor pin-out

40