′

$

Boston University

Electrical and Computer Engineering

SC464 Senior Design Project

Final Manual

Submitted to:

Boston University College of Engineering

656 Beacon St. #2

Boston, MA 02215

by

Team 5

Esplanade Runner

Team Members

Ilya Gribov

Rob Levy

Kevin Mader

Jimmy Ng

For the Period of Performance

September 4, 2006 May 4, 2007

Submitted: May 1, 2007

&

%

---

Contents

1 Introduction

5

1

System Layout .

6

2

System Communication .

7

3

System Specifications .

9

3-A

Proposal Specifications .

9

3-B

Specifications as Tested .

10

4

Project Budget .

10

2 Hardware and Sensors

11

1

Schematic and Wiring .

12

2

Mounting .

12

3

Compass Sensor .

14

4

Acoustic Sensors .

15

5

GPS Unit .

16

6

Site Selection for Testing .

17

7

Power Systems .

17

3 MCU

19

1

Functionality .

21

2

Programming and Debugging .

22

2-A

Programming .

22

2-B

Debugging .

23

3

Issues .

23

4 PDA

25

1

Introduction .

25

2

Functionality .

25

3

Programming and Debugging .

27

4

Issues .

28

5 RouteDraw Web Tool

31

1

Functionality .

32

2

Programming and Debugging .

33

3

Issues .

33

1

---

2

CONTENTS

6 Simulation Tools

35

1

Functionality .

36

1-A

Full System Simulation

.

36

1-B

PDA Testing Simulation .

37

2

Programming and Debugging .

38

3

Issues .

38

7 Basic System Operation

41

1

Site Selection .

42

2

Route Drawing .

42

3

Loading PDA .

43

4

Running the Esplanade Runner .

43

5

Issues .

44

A Component Specification Sheets

47

1

Garmin eTrex PDA Specifications

.

48

2

CMPS03 Magnetic Compass Chipset .

49

3

MMP-8 Mobile Robot Platform .

50

4

SRF05 Ultra Sonic Ranger .

51

5

M68DEMO908GB60 MCU Board .

52

6

Hewlett Packard iPAQ RX1955 PDA .

53

7

GPS TEXT Output Communication Format

.

54

8

MCU Internal Schematic .

57

B Specification Discussion

59

C Future Steps

61

1

RouteDraw Web Tool .

61

Glossary

63

---

List of Figures

1.1

Vehicle in attack-mode .

5

1.2

Diagram Showing the Flow of Control in the System .

8

1.3

Diagram Describing System Communication .

9

2.1

3D Model Used for Acoustic Sensor Placement .

11

2.2

System Schematic

.

12

2.3

A picture of the vehicle with all the components mounted .

13

2.4

Compass Chipset .

14

2.5

Acoustic Sensor Chipset .

15

2.6

Acoustic Sensor Timing Diagram .

16

3.1

MCU Development Board .

19

3.2

MCU USB Programmer Setup

.

23

3.3

MCU Connection Manager Settings Panel .

23

3.4

Hyperterminal Serial Port Settings .

24

4.1

Logging Screen showing the entries recorded for a very small course

.

26

4.2

Visual Studio 2005 Create Project Window .

28

4.3

The Debug Menu allowing the user greater control of the PDA functionality and

the system settings .

29

5.1

Drawing a route around the baseball diamond using the WebTool .

31

6.1

Simulation of the MCU and Vehicle Dynamics .

35

6.2

The results of a simulation where the compass is poorly calibrated and has a large

steady-state error the top graph is the vehicle path the bottom graph is a plot

of the compass readings vs. time where the red is the actual orientation and the

blue is the compass output

.

39

7.1

A field test being conducted in Amory Park .

41

7.2

Parameter Screen on EspRunner application running in PDA emulation environ-

ment .

44

A.1 The Acoustic Sensor′s Beam Profile

.

51

3

---

---

Chapter 1

Introduction

Figure 1.1: Vehicle in attack-mode

5

---

6

CHAPTER 1. INTRODUCTION

Executive Summary

The task of autonomous vehicle navigation coupled with obstacle avoidance is a notoriously

difficult problem involving communication with a variety of sensors and a motor control system

in real time. Our project is to create a system that will enable a mobile platform to navigate

a given route, while avoiding obstacles in its path. This system consists of a portable digital

assistant (PDA), a microcontroller unit (MCU), and three different sensory devices, namely, a

Global Positioning System (GPS), a digital compass, and acoustic sensors. The combination of

the PDA and MCU algorithmically interacting with these sensor devices creates a system that

maneuvers a vehicle through a user-determined route.

1

System Layout

The concept behind this system is to utilize the information from all of the sensors to determine

the answers to a few simple questions; where are we, where do we need to go and how do we get

there?

We utilize a handheld GPS unit to pinpoint the vehicle′s current location (longitude, lati-

tude), along with where we need to go. By using a digital compass to correctly orient ourselves

in the desired direction, we repeat this procedure iteratively until we′ve successfully completed

our route.

There are four main elements to this process: the web application, the PDA, the MCU and

the sensory devices each playing a role to the overall function of the vehicle.

The web application has three main functions. The first function is a web tool based on

Google Maps that allows any user to use the satellite imagery of the earth and define a waypoint

based route using only a few simple mouse clicks. The second of these functions is to translate

the user defined route into a series of longitude and latitude coordinates that the PDA program

will later use as the basis for its positional information. The last function is creating a file that

can then can be transferred and read by the PDA as a map.

The PDA application has two main functions. The first of which is determining current

location, desired location and all relative information required to connect the two. The PDA

does this by requesting GPS data via the MCU. Once the PDA receives the requested data,

the PDA uses the vehicle′s current position and the next waypoint in the route file that was

generated by the web tool and calculates the direction between its current position and the next

waypoint. The PDA sends this angle as a command to the MCU which translates that command

into signals to the motors. In addition to this navigation command, the PDA also serves as the

user interface for the entire system. From this UI, the user can start/stop the vehicle and set

parameters pertinent to system operation (forward and rotate speed, sensor threshold, toggling

obstacle avoidance, etc).

The MCU plays an important role in directly interacting with the sensors and providing

real-time when they are needed such as during obstacle avoidance and turning. It is in charge

---

2. SYSTEM COMMUNICATION

7

of communicating, relaying and interpreting all data that passes through it. The MCU links

the PDA, GPS unit, digital compass, acoustic sensors and motor control of the vehicle into a

single coherent unit. Each of our components employ a distinct communication protocol and

attempting to link them without a central unit to understand and standardize them would prove

extremely difficult if not impossible. From the perspective of the entire system the PDA serves

as the master and the MCU as the intermediary and the remaining components as the slave.

When requested by the PDA, the MCU requests data from the GPS and compass and forwards

it back to the PDA.

While the system is operating, the MCU functions also as an obstacle watchdog constantly

pinging the acoustic sensors to determine if an obstacle exists anywhere near the body of the

vehicle. If the sensors indicate there is an obstruction in its path, the MCU uses its real-time

obstacle avoidance algorithm to steer clear of the object and continue along with its path once it

has cleared the obstacle. The last function of the MCU is to generate signals to the motors known

as pulse width modulation (PWM) that control the speeds at which the motors rotate.

The sensor units each have one primary function, and that is to acquire data indicating

whether there is an obstacle in front of it. The sensors are positioned so that it is able to detect

potential obstacles on the left side, right side, and in front.

The handheld GPS communicates with satellites in the sky and sends data regarding its

exact location on the earth in terms of longitude and latitude coordinates. The GPS is connected

to the MCU via serial- port and is constantly transmitting the coordinates of its current location.

The digital compass′ provides the deviation from magnetic north. The compass is used to

position the vehicle at the correct angle, in order to head in the right direction. It communicates

with the MCU by means of the I2C protocol. The acoustic sensors are then used to detect if an

obstacle is blocking the path of the vehicle.

2

System Communication

Communication between the different components is essential to the core of our system. Because

the MCU acts as the central control unit, all components communicate via different protocols

to ensure that all data do not end up on the same bus and thus risking data interference.

The GPS communicates with the MCU through a serial port connection. This data transfer

is a one way (MCU does not request data from the GPS, MCU selectively ignores data bursts

until the PDA requests it) in which the GPS constantly sends all information regarding current

coordinates to the MCU in a string format output.

The acoustic sensors are connected to the MCU by a general purpose IO port. When

information from a particular sensor is requested, a pulse is generated by the MCU, sent down

the line which is translated by the sensor′s internal circuitry into an ultrasonic acoustic pulse

emitted by the sensor chip. When the acoustic pulse returns (echo), the sensor chip translates

the response into another pulse which is sent back to the MCU on the same IO port. By using

the linearly proportional relationship of time between pulse and echo and speed of sound, the

MCU can determine the distance at which an object is detected.

---

8

CHAPTER 1. INTRODUCTION

Acoustic

GPS

Sensors

Digital Line

Serial

MCU

PDA

Poll

Buffer 110

Request and

Acoustic

characters of

Serial

Pause 1 Second

Read GPS

Sensors

GPS output

Calculate

Avoid Obstacles

Distance and

and Ignore PDA

Angle to Current

Waypoint

Turn until

Set

orientation

Desired

matches

Angle

Is within 10

Load Next

feet of

Yes

Waypoint

waypoint

Set

Read

Serial

PWM

Compass

No

Signals

Send Angle

Dual PWM

I2C

to Next Point

Channels

Platform

Compass

Figure 1.2: Diagram Showing the Flow of Control in the System

The compass is then connected to the MCU via I2C interface. Through the I2C interface

the compass sends its current heading to the MCU in byte form, where the MCU can then use

this information to rotate the vehicle to the desired heading.

The PDA is connected to the MCU through the MCU′s second serial port. This connection

is a bi-directional communication in which the PDA and MCU can send information back and

forth. The MCU takes the GPS data string that it receives and forwards this information to the

PDA. Once the PDA calculates the angle that the vehicle should rotate, it then sends this angle

back to the MCU through the serial port connection with instructions to rotate the vehicle until

the desired heading is reached.

The MCU′s PWM module is responsible for regulating the signals sent to the motors are

responsible for vehicle motion. Based on the MCU′s instructions of how fast and which direction

the vehicles motors should rotate, the MCU will send a duty cycle pulse of 1.0 - 2.0 milliseconds,

1.0ms being the maximum reverse speed, 2.0ms being the maximum forward speed, and 1.5ms

being the dead zone.

---

3. SYSTEM SPECIFICATIONS

9

100us to 25ms

echo pulse

GPS

(serial port

NMEA standard GPS

#2)

data sentence

10us min trigger

Sensors (4)

pulse

Sensor, GPS and

compass readings

MCU

Compass

Course adjustment

PDA

instructions

I2C

(serial port

interface

1 byte

#1)

compass heading

Left Right

PWM motor

control

Signal

0 ­ 100% duty

cycle value

Mobile

Platform

Interface: PWM

input port

Figure 1.3: Diagram Describing System Communication

3

System Specifications

In out initial proposal we produced a number of specifications for the operation of our vehicle

and system based on simulations, research, and manufacturer specifications.

3-A

Proposal Specifications

Vehicle and onboard computers Specifications

· Operational Specs

­ Minimum operating speed is 1 foot/second

­ Climbs 10% grades

­ Operates anywhere with GPS coverage

­ Operates for at least 1 hour without recharging

­ Operates on 12V battery pack

­ Operates on concrete or short grass surfaces

­ Adapts route to avoid objects greater than 20cm × 20cm × 20cm

­ Withstands impact of up to 1 foot/second without loss of performance

---

10

CHAPTER 1. INTRODUCTION

­ Will navigate the predefined route within a 20 foot radius

· Modular Design (components can be removed and added)

­ Sensor Units

­ GPS supporting UART & NMEA

3-B

Specifications as Tested

· Vehicle is within 5-10 feet of desired route, in the absence of obstacles, given a GPS fix of

3 or more satellites

· Vehicle travels at 2.5 feet/second and the speed can be adjusted from 0.7 feet/second to

3.7 feet/second

· Vehicle can climb 20% grade

· Vehicle operates for approximately 40 minutes depending on conditions

· Vehicle is easily capable of navigating concrete, grass, dirt paths, and bumpy fields. Per-

formance however as the terrain quality decreases.

· Withstands impact of up to 3 feet/second into solid object (testing on tree) without loss

of performance

· Vehicle avoids obstacles with at least a 15cm × 15cm cross section to the vehicle sensors

· Vehicle communicates with GPS using TEXT standard developed by Garmin and available

in all of their products

The discrepancies and changes made between these two specifications are discussed in detail in

Appendix B (Page 59).

4

Project Budget

Item

Cost ($)

MMP-8 Mobile Robot Platform

$795.00

Garmin eTrex GPS

$74.93

R117-COMPASS

$52.00

KIT-HCS08GB-USB

$499.99

HP iPAQ rx1955

$249.99

R271-SRF05(Acoustic Sensors)

4 × $25.00

Mounting Materials

$20.00

Total

$1791.91

---

Chapter 2

Hardware and Sensors

Figure 2.1: 3D Model Used for Acoustic Sensor Placement

The hardware and sensors are a crucial area of the project since this is how all everything is

physically connected together and the communication methods between components. Much of

our time was spent this semester in determining and documenting how many of these standards

worked because the available material was not adequate.

11

---

12

CHAPTER 2. HARDWARE AND SENSORS

1

Schematic and Wiring

J2

CONN DSUB 9-R

DB9

5

9

Connector

0

4

8

3

7

for

2

6

PDA

1

SRF05

+5

5V

M68DEMO908GB60

NA

Sensor

TPM2CH4

GPS

2AA

I/O

PDT7

SCI1_Tx

Mode

TPM2CH3

VDD

V1

Batteries

GND

PTD6

SCI1_Rx

GND

3Vdc

TPM2CH2

0

Rx

Acoustic

0

PTD5

SCI2_Rx

Tx

SRF05

TPM2CH1

PTD4

+5

PWM1

VDD

V2

5V

PTD1

2

3

3Vdc

NA

C

C

Sensor

PWM0

GND

2AA Batteries

I/O

PTD0

PT

PT

Mode

GND

J3

Acoustic

0

SCL

SRF05

Right_Motor_Input

1

2

+5

+5

3

5V

NA

Sensor

I/O

CON3

Mode

0

3Pin connector MMP-08

GND

J4

Acoustic

0

Left_Motor_Input

1

SRF05

2

+5

3

+5

5V

NA

Sensor

CON3

I/O

0

3Pin connector MMP-08

Mode

CPMS03-Compass

GND

9

GND

SW1

Acoustic

0

8

NA

Switch for Calibration

7

50/60Hz

6

Calibrate

5

NA

4

PWM

0

SW_PB_SPST

SDA

3

SDA

2

SCL

+5

0

R1

+5

47k

R2

47k

Figure 2.2: System Schematic

2

Mounting

The way in which we mounted all the hardware on vehicle was important in the design process

because nothing could be drilled or permanently attached to the car. Everything connected to

the actual vehicle must be temporary. Because the vehicle is built on two separate planks that

move up and down individually, we could not mount all the components on one plane and rest it

on the entire surface. To overcome this challenge, we created a system that is raised above one

side of the vehicle so that it will not interfere with the up and down motion of the two planks. A

cork plate is used to support the PDA, the GPS, the MCU, and the compass. To attach all the

components we use double sided velco tape. Velcro is the ideal mounting material because it is

strong and will support the weight of the components, yet it is temporary and does not destroy

---

3. COMPASS SENSOR

13

Figure 2.3: A picture of the vehicle with all the components mounted

the vehicle. All the components are therefore attached to the cork plate via the velco tape. This

enables the user to detach all the components at will and reattach them with ease. The sensors

are connected to metal L shaped brackets using electrical tape which are strategically placed to

maximize the visibility of obstacles. Two sensors attached to brackets are velcro′d to the vehicle

in front, and two are placed on the sides of the vehicle (one on each side). The plastic plate is

raised 4 inches from the car to clear the sensor brackets as well as the vehicles bidirectional up

and down motion of the two sides. To raise the plate, there is a wooden bridge type support

system that is attached to one side of the vehicle by Velcro, also allowing the user to detach it

at will.

---

14

CHAPTER 2. HARDWARE AND SENSORS

Figure 2.4: Compass Chipset

3

Compass Sensor

The compass chipset that we have selected is the Devantech Magnetic Compass Module CMPS03

shipped with software revision 3 stored on the chip′s EEPROM. Depending on what the capa-

bilities exist on the master you wish you communicate with, this chipset supports communi-

cation via Inter-Integrated Circuit (I2C) or Pulse Width Modulation (PWM). Power supply is

5V with a nominal current draw of 15mA. For our particular implementation, we have cho-

sen to utilize the I2C method which requires a pull-up on both the Serial Clock Line (SCL)

and Serial Data Line (SDA). This protocol was chosen because measuring PWM will be in-

accurate by the MCU. Internal software pull- ups may be used on the master device if sup-

ported, however we decided to use two 47k resistors. Information on the PWM method can

be found at http://www.robot-electronics.co.uk/htm/ cmps3doc.shtml Calibration of the com-

pass can be done by orienting the compass in each of the four cardinal directions and con-

necting Pin 6 to GND. This must be done for each of the four cardinal directions and must

be accurate.

This procedure is most simply done by using a push button switch to con-

nect Pin 6 to GND and an analog compass to ensure that the orientation during calibration

is accurate.

Below are the pin connections that are used during operation of the vehicle.

Pin 9 (0v Ground)

connected to the vehicle′s ground (common ground on MCU)

Pin 8 (No Connect)

Unconnected

Pin 7 (50/60Hz)

Unconnected

Pin 6 (Calibrate)

Used once for initial calibration, unconnected during operation

Pin 5 (No Connect)

Unconnected

Pin 4 (PWM)

Unconnected

Pin 3 (SDA)

Connected to MCU PTC2

Pin 2 (SCL)

Connected to MCU PTC3

Pin 1 (- + 5v)

Connected to a 5v line from the vehicle

Limitations

There are a number of environmental factors and situations that limit the relia-

bility and accuracy of our compass. These factors include proximity to large steel objects, degree

of incline from the earth′s plane and the existence of systems with substantial electromagnetic

fields. The operation of our vehicle in the proximity of large steel objects substantially affects

---

4. ACOUSTIC SENSORS

15

the readings of our compass. This includes operating it on a surface or ground that is reinforced

with steel beams (Photonics ground floor) or large metal objects (cars or trucks). This anomaly

was verified by approaching a parked car with an analog compass near observing it veer more

than 20 degrees. Photonics ground floor also exhibited similar inconsistent behavior with an

analog compass. Gradually lowering the compass from 5 feet to the ground showed the needle

veering as well. Operating the vehicle on extremely rough terrain (sudden drops of > 4 inches),

inclines of greater than 30% will cause the compass to output garbled results. Currently, our

MCU code is not able to handle these abnormal events or reset the compass to normal operation.

When this event occurs, the vehicle will go into a constant rotation mode presumably trying to

rotate to a desired bearing but the MCU is not able to match its desired bearing because the

compass is outputting invalid results. This can be rectified by resetting the compass′ 5v power

supply (vehicle). This deviation from the plane can also be caused by the chipset wobbling

during operation. The compass must be secured to the breadboard to prevent this wobbling.

Operating the chipset near or around systems with a substantial electromagnetic field will neg-

atively the operation of the compass. Systems such as oscilloscopes, signal generators, cellular

phones all should not operated near ( > 0.5 feet) from the compass. However, removing the

disrupting system allows the compass to resume normal operation without manual resetting of

the power. Motors can also emit a substantial electromagnetic field. It is for this reason that

we have mounted the chipset approximately 4-5 inches above the motors itself.

4

Acoustic Sensors

Figure 2.5: Acoustic Sensor Chipset

Our selection of ultrasonic sensors is the SRF05 sensor. This particular model was chosen

for its ranging capabilities (4cm to 4m) which suited a project of our scale, detecting obstacles

big enough that it is unable to climb over and ignoring others that can easily be tread over.

The SRF05 is an acoustic sensor which uses ultrasonic acoustic waves to determine a distance

of an object. The sensor sends out a 40kHz wave, listens for echoes which will bounce off of

objects. Using the difference in time between when it sends out the pulse and when it records

an echo, the distance of an object can be determined. To initiate the sensor it has to receive a

10uS pulse. Once it receives it will generate a pulse on the same line it received a 10uS pulse

on. The duration of this pulse is proportional to the distance of the detected object. The pulse

---

16

CHAPTER 2. HARDWARE AND SENSORS

will be between 100uS and 25mS long. Taking the duration of the pulse in microseconds and

dividing it by 58 will be the approximately the distance to the object in centimeters.

Figure 2.6: Acoustic Sensor Timing Diagram

Limitations

The sensor′s ultrasonic pulse is a cone-shaped beam. Assuming an impending

obstacle false within the path of its beam, it is able to detect it in time to avoid crashing into

it. The problem occurs when the vehicle is tilted above or below the plane of the earth thus

orienting its sensors towards the sky or directly into the ground. When this occurs, the system

can falsely construe the earth as an object.

During operation, the sensors are fired sequentially to avoid pulses and echos from inter-

fering with another sensor.

5

GPS Unit

We use the Garmin eTrex GPS in order to obtain current positional information. The unit is

designed as an outdoor unit for use in hiking or similar activities. This means that the device

is waterproof, powered by its own set of batteries and shock resistant. While the current scale

of our project does not necessitate these features they do provide the opportunity for future

teams to evolve the project into a more rugged system. For the purposes of this project the

GPS acts as a black box that spits out our location with some error term. Site selection and

environmental conditions are important for limiting the error term, but for the most part error

is ignored. The GPS also has a variety of other features such as tracking, position logging, and

similar features that we do not currently use.

Limitations

The GPS is also susceptible to so quite a few different external factors which

determine the overall accuracy of the fix and consequently the reported Horizontal Dilution of

Precision (HDOP). The main factor that contributes to this accuracy is the view of the sky

available at a testing site. In large empty fields with no nearby buildings, the accuracy is very

high and the vehicle can navigate within a couple of feet of the path. In more urban settings

with lots of buildings, the accuracy can extend to more than 15 feet of error.

---

6. SITE SELECTION FOR TESTING

17

One of the factors that we have not investigated but could be present is electromagnetic

interference originating from the PDA or MCU. This is briefly explained in the following article

(http:// www.tech.co.uk/gadgets/satellite-navigation/in-car-gps-installs/news/

your-pc-could-knock-your-gps-out?articleid=2046970035)

6

Site Selection for Testing

For the vehicle to be able to navigate accurately within the specs defined above, the vehicle

must have accurate sensor information. The two sensors most susceptible to external factors are

the GPS and the compass (detailed further in later sections).

The GPS unit works by locating as many satellites orbiting the earth as possible, and trian-

gulating the combination of these signals to find the exact coordinate it is currently positioned

at. This means that the unit must have a clear view of the sky in order to locate and receive

signals from the satellites. A field or big parking lot is an ideal site to run the vehicle because

there are no obstructions that block the GPS′s view of the sky. Running the vehicle in locations

where large buildings ( > 6 stories) are close by will block part of the GPS′s view of the sky

therefore limiting the number of satellites the unit can locate. This in turn will significantly

decrease the accuracy of the GPS, causing the vehicle to stray off the path of the route. Due

to GPS limitations, the vehicle will not work indoors. An optimal site to run the Esplanade

Runner is anywhere in which the GPS unit has a decent horizontal view of the sky as well as a

clear vertical view of the sky.

The digital compass uses the local magnetic field to calculate direction. Because of this,

any objects which can cause even a slight fluctuation in the local magnetic field can cause the

compass to report an incorrect orientation. These disruptive objects can range from a cell

phone to a parked car. This is most notable in or around large buildings with steel reinforced

structures such as the Photonics Center and in parking lots with parked cars. Several of the

tests we conducted failed because of our inability to anticipate the deviation caused by these

disrupting factors.

7

Power Systems

The system involves 4 separate power systems because all the components are designed to

function independently in a modular way.

1. MCU Power

The MCU is powered by 2 AA batteries that are easily user replaceable and have an

expected life in excess of 10 hours.

2. GPS Power

The MCU is powered by 2 AA batteries that are easily user replacable and have an expected

life in excess of 20 hours.

---

18

CHAPTER 2. HARDWARE AND SENSORS

3. Vehicle Power

The MMP-8 contains a rechargeable NiCad battery. It has 10 individual cells which

comprise a 12V 1400mAh total. The battery should be charged at a rate of 2000mAh.

The vehicle has an expected life of around an hour and as battery life decreases the wheel

speeds and torques decrease rapidly.

4. PDA Power

The PDA has an internal rechargeable 1100 mAh Lithium ion battery and has an expected

life in excess of 10 hours. The batteries can be recharged by either USB or the included

cradle.

---

Chapter 3

MCU

Figure 3.1: MCU Development Board

The MCU serves three primary purposes as the core our system; data acquisition and

reporting, obstacle avoidance and PWM motor control. The data acquisition and reporting

role of the MCU involves waiting for a request from the PDA and servicing that request. Upon

receiving the appropriate command, the MCU buffers the GPS for current longitude and latitude

coordinates. Between the MCU and PDA, the MCU always serves as the slave, waiting for a

request from the PDA and then responding to it. Once the MCU receives a request from the

PDA, the MCU accepts data from the device the PDA has requested (prior to a PDA data

request, the MCU is selectively ignoring continuous input from all of the devices and only

19

---

20

CHAPTER 3. MCU

records once the PDA makes the request).

Obstacle avoidance is the second of the MCU′s responsibilities. This job consists of pinging

each of the four acoustic sensors sequentially and initiating routines based on its responses. If

all four sensors echo a negative (no obstacles), the code continues to run skipping all obstacle

avoidance vehicle control actions. If however, any number of the sensors echoes a positive, this

indicates that there is an impending obstacle in its path. When this happens, the MCU initiates

code to guide the vehicle away from the obstacle dependent entirely on the configuration of

positive and negative sensor responses. The responses are outlined in Table 3.1

Sensor Readings

Vehicle Response

Top-Left

Top-Right

Left Side

Right Side

F

F

Continue Navigating Normally

T

F

Turn the Vehicle Left

F

T

Turn the Vehicle Right

T

T

F

F

Turn the Vehicle Right

T

T

T

F

Turn the Vehicle Right

T

T

F

T

Turn the Vehicle Left

T

T

T

T

Have vehicle move backwards

Table 3.1: Obstacle Avoidance Response Table

The third and last responsibility of the MCU is PWM motor control. Our MCU has a

PWM module which allows us to control and change PWM signals in parallel with main code

that is executing at the same time. The MCU receives a wide range of vehicle movement

commands from the PDA and executes them. For example, when the PDA senses that vehicle

has reached a waypoint (based on GPS input), the PDA sends a command to the MCU to

rotate a specific direction. During this time, the vehicle will be rotating and the MCU will be

constantly comparing the current heading to it′s desired heading and resume forward motion

when these two values are within a tolerance.

It is important to note that the MCU does not make any vehicle control decisions while

in normal operating mode (obstacle-free). During normal operation, the MCU simply receives

vehicle control decisions from the PDA and executes them in the form of PWM signals.

---

1. FUNCTIONALITY

21

1

Functionality

Below is pseudo-code outline of MCU general functionality code

1. Pseudo-code for MCU′s main loop

while(RUNNING)

{

switch(COMMAND)

{

(a) STOP;

(b) TURN_TO_DESIRED_HEADING;

(c) READ_GPS_AND_SEND_TO_PDA;

(d) SET_PARAMETERS;

}

OBSTACLE_AVOIDANCE;

}

(a) STOP sets the PWM signal to the dead zone (wheels are stationary)

(b) Compares current compass reading to desired bearing. Turns until the compass read-

ing matches the desired reading plus a tolerance (which compensates for the compass′s

sensitivity).

(c) Enables SCI2 port and interrupt, waits until the GPS buffer is full and sends it to

the PDA over serial.

(d) There are several user adjustable debugging parameters such as forward speed, turn

speed, and obstacle avoidance tolerance. Also to turn on and off obstacle avoidance.

2. Pseudo-code for Obstacle Avoidance

OBSTACLE_AVOIDANCE

{

switch(WHICH_SENSOR_SEES_OBJECT)

{

TOP_LEFT AND TOP_RIGHT:

{

if(LEFT) then TURN_RIGHT

elseif(RIGHT) then TURN_LEFT

elseif(LEFT AND RIGHT) then

REVERSE

}

TOP_RIGHT:

{

TURN_RIGHT

}

TOP_LEFT:

---

22

CHAPTER 3. MCU

{

TURN_LEFT

}

}

· The variables here are treated as booleans because they are chopped off based on the

tolerance parameter given. For example, distance reading from the sensor < 50 cm

True, 50 cm False

· TOP LEFT = The status of the sensor mounted on the top left side of the vehicle

· TOP RIGHT = The status of the sensor mounted on the top right side of the vehicle

· RIGHT = The status of the sensor mounted on the right side of the vehicle

· LEFT = The status of the sensor mounted on left side of the vehicle

3. Interrupts

(a) Fill command buffer from SCI1 (RS232) port.

(b) Generate pulse to turn on sensors.

(c) Read sensor pulse width

4. PWM - Continuously running

(a) 2 PWM signals ranging from 1ms to 2ms pulse width.

(b) 1.5ms dead zone for vehicle (Stopped)

(c) Shorter than 1.5ms wheels spin forward

(d) Longer than 1.5ms wheels spin in reverse

2

Programming and Debugging

2-A

Programming

1. Connect USB cable to computer and to In-Circuit Debugger (Figure 3.2)

2. Connect ribbon cable to 6 pin debugger port on development board.

3. Run CodeWarrior.

4. Press play. If there are no errors in the code the connection manager window will pop up.

5. Press Connect. This (Figure 3.3) will program the microcontroller.

---

3. ISSUES

23

Figure 3.2: MCU USB Programmer Setup

Figure 3.3: MCU Connection Manager Settings Panel

2-B

Debugging

1. Debugging Window allows you to step through code.

2. Connect SCI1 to serial port of PC. Run hyper-terminal. Use settings shown in Figure 3.4

3. Key strokes entered in hyper-terminal will be transmitted over to the MCU.

3

Issues

1. When using CodeWarrior to debug the code the MCU will occasionally reset when the

BDM debugger is connected.

2. The MCU will hang when the Compass is reset because the MCU remains waiting for the

stop bit

---

24

CHAPTER 3. MCU

Figure 3.4: Hyperterminal Serial Port Settings

---

Chapter 4

PDA

1

Introduction

The PDA serves two purposes. The first purpose is to serve as the user interface for the entire

system. The PDA contains a GUI in which the user can control the vehicle′s motion, set param-

eters for operation (sensor threshold, turning and forward speeds) and start/stop navigation.

It also is used to receive data from the GPS unit and send instructions to the MCU based on

the data it receives. There were two main requirements for the selection of the PDA. The first

requirement from our customer was that the unit had to be running Windows Mobile. Windows

Mobile 5.0 is a user friendly operating system that provides a straightforward programming

environment. The second requirement was that the PDA must have a serial-port connector in

which the MCU can be attached to. This also provides straightforward communication methods.

After careful consideration, the HP iPAQ rx1955 Pocket PC was selected as the best and most

cost efficient PDA. The iPAQ has a 300MHz processor and has 36MB of user memory so that

multiple programs and files can be stored.

2

Functionality

The user interface on the PDA is very important because it is the only link that the user has

to the system and its operating parameters. The main screen of the program is used to display

the current information that the PDA is processing. Once the .gpx file is loaded onto the PDA,

all the waypoints that the vehicle needs to traverse are listed in the top textbox of the GUI.

The waypoints are displayed with information regarding exact location in terms of longitude

and latitude, as well as a checkbox to notify the user if that particular waypoint has been hit by

the vehicle. As the vehicle traverses the defined route, the waypoints are successfully checked

off one by one. Below the top textbox are two numbers showing the angle sent to the MCU that

the vehicle must rotate to, and the distance to the next point in feet.

Located at the bottom of the GUI, there is a toolbar that contains GPX, MCU, and

25

---

26

CHAPTER 4. PDA

Debug. The GPX menu is used to load the route the user wishes to traverse, as well as the

Start Navigation command. The Debug menu is used to access and set different elements of the

system, such as parameters, or to halt navigation. The Set Parameter menu is used to set vehicle

speeds, set compass offset, turn obstacle avoidance on or off, and set whether the logging of all

information sent from the MCU is sent to a text file. The Set Parameters menu also contains a

GPS polling setting in which the user can adjust the period at which the PDA polls the MCU

for the GPS reading in milliseconds. The larger the polling time, the smoother the vehicle will

drive but this causes a less accurate route traversal because corrections occur less frequently.

The MCU menu at this time is not used and serves no immediate purpose.

Figure 4.1: Logging Screen showing the entries recorded for a very small course

The other function of the PDA is to receive coordinates from the GPS unit, and to then

calculate the desired direction the vehicle should move to reach this location. The PDA applica-

tion contains a timer in which every few seconds it sends a request to the MCU and asks for GPS

information. The GPS will then send its current location in longitude and latitude to the PDA

via the MCU. The PDA will then use this information and compare it to the current waypoint

in the .gpx file containing where the vehicle should go, and determine the correct orientation the

vehicle should be positioned at to head towards the desired coordinate. The PDA then sends

this angle to the MCU, which in turn tells the vehicle to rotate to this angle so it will have the

correct orientation to head in a straight line to the next waypoint.

---

3. PROGRAMMING AND DEBUGGING

27

1. PDA Pseudo-code

while (RUNNING)

{

(a) REQUEST_GPS_FROM_MCU;

(b) CALC_DISTANCE_AND_ANGLE_TO_NEXT_POINT;

if (DIST<TOLERANCE_DISTANCE)

{

(c) SEND_ANGLE_TO_MCU;

} else {

(d) LOAD_NEXT_POINT;

}

}

(a) Requests the current position from the MCU by writing a ′G′ to the serial port

(b) Calculates the distance and angle to the next point using standard formulas

(c) Sends the angle calculated to the MCU by writing ′AXXX′ to the serial port where

XXX is the angle in degrees scaled to 255 instead of 360

(d) Once the vehicle is within the tolerance of the desired point it loads the coordinates

for the next waypoint

3

Programming and Debugging

A PDA running Windows Mobile 5.0 was the most desirable because it provides the programmer

user friendly methods for writing applications. The PDA is programmed using Visual Studio

C#. Visual Studio provides a Pocket PC emulator that simulates a PDA and allows one to

easily write a PDA application. The programming language C# also enables one to easily

create graphical user interface screens by simply dragging methods from the library and placing

them on the C# form.

To create a Pocket PC application:

1. Install Visual Studio 2005

2. Download and install Pocket PC from the Microsoft web page.

http://www.windowsdevcenter.com/pub/a/windows/2006/01/24/

windows-mobile5-emulators-in-visual-studio-2005.html

3. Open Visual Studio 2005 Create Project

4. Select Visual C# Smart Devices Windows Mobile 5.0 Device Application name

5. Once the Form1.cs is open you can begin programming on the emulator.

---

28

CHAPTER 4. PDA

Figure 4.2: Visual Studio 2005 Create Project Window

6. To compile your program, on the top toolbar click Debug Start Without Debugging.

Select Windows Mobile 5.0 Pocket PC Emulator.

7. Click Deploy.

This will run the emulation of your Pocket PC application.

To run the program on your actual PDA:

1. Go to:

C:\My Documents\Visual Studio 2005\Projects\(name)\(name)\bin\Debug\

This folder contains the executable file of the application you created.

2. To put on PDA, copy the executable file onto your SD memory card and then put the card

into the PDA SD card slot.

3. Then simply navigate in the PDA to your program and run it.

4

Issues

One of the earlier issues we faced was a high incidence of faulty communication between the

MCU and the PDA through the serial port. Commonly bits were lost or entire strings were not

read for no apparent reason. The fault was likely the drivers buried deeply in Windows Mobile

because we did not experience the problems at all when using HyperTerminal. So the PDA

application was designed to be very fault tolerant to prevent such issues from halting the vehicle

operation.

One of the main issues when designing the system was that C# is not a real time pro-

gramming language. This means that the code written for the PDA will execute on top of all

of the system code. This means that the PDA cannot be relied on for fast communication and

computation in the same way the MCU can. The MCU for example can constantly poll the

---

4. ISSUES

29

Figure 4.3: The Debug Menu allowing the user greater control of the PDA functionality and the

system settings

sensor hardware for new information and discard it at will. The PDA can not constantly poll

other hardware devices for data and also can not discard information at will to free up memory.

Managed code like C# must wait for garbage collection to clear out all unused data from the

memory. This will sometimes cause the PDA to hang and be unresponsive to all communications

and processes it should be executing. During the creation of this system, we concluded that

this garbage collection will not be an issue because the PDA will only be polling the GPS and

compass every few seconds, which represents millions of clock cycles on the PDA. With this in

mind, the PDA application will hang due to Windows Mobile and PDA related issues, but the

infrequent nature of this event did not cause any issues for testing and only required us to reset

the PDA unit several times.

---

---

Chapter 5

RouteDraw Web Tool

Figure 5.1: Drawing a route around the baseball diamond using the WebTool

The RouteDraw web tool is designed to allow for streamlined creation and editing of routes

for the vehicle to navigate using satellite imagery to guide the placement of the points in the

route. This feature is important to the project success because the idea behind the project is

that a user with minimal training would be capable of designating the route.

31

---

32

CHAPTER 5. ROUTEDRAW WEB TOOL

1

Functionality

The website is based on the Google Maps API with our program written on top of the map

layer to allow clicking, dragging, and recording of latitude and longitude points. The program

then produces an XML output file made to GPX standards that can be read in many different

mapping packages and by our PDA unit.

The pseudo-code for the site:

1. Data Recording

while (CLICK)

{

(a) RECORD_MOUSE_POSITION;

(b) TRANSLATE_POSITION_TO_LAT_LON;

(c) UPDATE_ROUTE;

if (MOUSE_DOWN)

{

CLICK=FALSE;

}

}

(a) This function was taken and slightly modified from another site which had the code

as public domain.

(b) This function was done by taking the borders of the screen and the latitude and

longitude limits for the map view and determining the linear relationship between

the two. We know this works accurately because the line drawn is drawn using the

latitude and longitude coordinates and it directly corresponds to the position of the

mouse

(c) The point is then appended to the end of the route

2. Route Drawing and GPX Creation

if (CLICK)

{

for(i=0;i<POINT.LENGTH;i++)

{

(a) DRAW_MARKER(POINT(i));

(b) DRAW_LINE(POINT(i),POINT(i-1));

(c) APPEND_GPX(POINT(i));

}

(d) NEW_WINDOW(GPX_FILE);

}

(a) This command uses the Google Maps API to draw a draggable marker at the current

point

(b) This command draws a line between the previous point and the current point

---

2. PROGRAMMING AND DEBUGGING

33

(c) The command here is slightly more complicated because it appends the following line

which contains the current point wrapped in a GPX format

<trkpt lat="′+POINT(i).LATITUDE+′"

lon="′+POINT(i).LONGITUDE+′"></trkpt>

(d) This command adds the proper header and footer to the GPX file and opens a new

window containing the contents of the GPX file in a text box (otherwise some web

browsers will try to interpret it)

2

Programming and Debugging

The code for the site is almost entirely JavaScript with HTML used for layout. The javascript

powers the mapping, recording, and interface controls. Debugging can easily be done within the

browser since most modern browsers have a JavaScript console which will report which lines of

code caused trouble for the

3

Issues

Compatibility

The most common issue with the RouteDraw Web Tool is the browser com-

patibility issue. Since the JavaScript code being used is fairly complex it is not 100% compatible

with all browsers. Specifically Internet Explorer 6 will not run the code that tracks the mouse

while the route is being dragged out. The other browsers successfully tested have been : Firefox

2.0 on Windows XP, Vista, Mac OS X; Internet Explorer 7 on Windows XP and Vista; Safari

1.5 on Mac OS X; Camino 1.0.3 on Mac OS X

Erratic Bugs

Some erratic bugs have occurred rarely in the program when running in Firefox.

The most common is that the browser will lose track of the route and delete all the points

recorded. The bug can be worked around by clicking the clear button and re-entering the

route.

---

---

Chapter 6

Simulation Tools

1.0971

71.097

71.097

71.0969

71.0969

71.0968

71.0968

71.0968

71.0967

Longitude

Figure 6.1: Simulation of the MCU and Vehicle Dynamics

The simulation developed for this project contributed strongly to the overall success of

the project. Testing our project outdoors requires not only a significant time commitment, but

also cooperative weather therefore the ability to test code functionality, parameters, control

systems and other factors in a simulated environment allowed our team to obtain a high level

of functionality before going outside saving tens of hours of testing. The simulation code was

written in Matlab because of the short development cycle and the ability to immediately plot

and display results. The simulation is not one of the required deliverables for the project but

it represents a significant accomplishment and stepping stone to more exciting progress from

future teams.

35

---

36

CHAPTER 6. SIMULATION TOOLS

1

Functionality

There are two principal simulation tools that were written for testing and design purposes. The

first tool was meant as an early stage tool while the second provided the opportunity to test

specific completed components in a simulated environment.

1-A

Full System Simulation

The full system simulation was designed to simulate every aspect of the system simultaneously

most importantly sources of error. This simulation allowed for us to develop the initial algorithms

for vehicle navigation and obstacle avoidance. The next step for this testing is do determine the

sensitivity of the system to the errors in the components. Most importantly GPS error because

at least on paper that is our weakest link since its error can very up to around 15 meters which

corresponds to around 38 times the length of the vehicle.

1. Main Simulation Loop

while (RUNNING)

{

(a) READ_GPS;

(b) CALC_DISTANCE_AND_ANGLE_TO_NEXT_POINT;

if (DIST<TOLERANCE_DISTANCE)

{

(c) READ_ACOUSTIC_SENSORS;

if (SENSORS_CLEAR=FALSE)

{

while (SENSORS_CLEAR=FALSE)

{

(d) TURN_VEHICLE;

}

(e) GO_STRAIGHT;

}

(f) READ_COMPASS;

while ABS(COMPASS-ANG)>TOLERANCE_ANGLE

{

(g) TURN_VEHICLE;

}

(h) GO_STRAIGHT;

} else {

(i) LOAD_NEXT_POINT;

}

}

(a) Takes the current position and simulates a GPS by adding an error vector in a random

direction for a random distance up to 15 meters. The command also has some memory

---

1. FUNCTIONALITY

37

so the error vector remains constant for on average 4 readings

(b) Calculates the distance and angle to the next point using standard formulas

(c) Performs some fairly complicated math to project 4 cones from the vehicle and de-

termines if and where those cones intersect with any objects in the simulated envi-

ronment

(d) Turns the vehicle until the front sensors are both clear

(e) Forces the vehicle to go straight for a duration of time which is usually enough to

avoid most simple obstacles

(f) This command takes the orientation of the vehicle and simulates the compass by

adding a noise and a steady-state offset to that value

(g) This command has the vehicle go faster which ever side is closer to the angle the

vehicle needs to travel at to turn the vehicle while remaining relatively stationary

(h) This command just sends the same speed to both sides

(i) Once the vehicle is within the tolerance of the desired point it begins to head towards

the next point

1-B

PDA Testing Simulation

The PDA testing simulation was adapted and expanded from the complete simulation in order

to allow the PDA to perform its usual functions and have the program simulate all the other

aspects involved.

1. Main Simulation Loop

while (RUNNING)

{

switch(COMMAND)

{

(a) STOP;

(b) SET_DESIRED_HEADING;

(c) READ_GPS_AND_SEND_TO_PDA;

}

(d) READ_COMPASS;

while ABS(COMPASS-HEADING)>TOLERANCE_ANGLE

{

(e) TURN_VEHICLE;

}

(f) GO_STRAIGHT;

}

(a) STOP causes the simulation to stop running and close the serial port.

---

38

CHAPTER 6. SIMULATION TOOLS

(b) A set command comes from the PDA containing the heading the vehicle should travel

at

(c) This command takes the current position and simulates a GPS by adding an error

vector in a random direction for a random distance up to 15 meters. The command

also has some memory so the error vector remains constant for on average 4 readings.

It then generates a fake string containing the coordinates in the TEXT format and

sends that string to the PDA via the serial port

(d) This command takes the orientation of the vehicle and simulates the compass by

adding a noise and a steady-state offset to that value

(e) This command has the vehicle go faster which ever side is closer to the angle the

vehicle needs to travel at to turn the vehicle while remaining relatively stationary

(f) This command just sends the same speed to both sides

2

Programming and Debugging

The code has a number of parameters that can be set within the code to allow for testing of a

variety of different scenarios. Some of the results are shown below because they illustrate the

power of the simulation tools in determining a problem with the system.

3

Issues

The simulation does very simplistic modeling of the vehicle dynamics which is functional for

simple environments but if we tried to expand our project into other areas or a more interesting

terrain the model would be inadequate.

The errors are also modeled fairly simply as either completely random processes (dynamic

error), random processes with memory (gps error), or a random process with a constant offset

(compass error). The real error could likely behave in a more structured way to have an almost

negative resonance on the system where our model would predict the error as averaging itself

out over time.

---

3. ISSUES

39

Figure 6.2: The results of a simulation where the compass is poorly calibrated and has a large

steady-state error the top graph is the vehicle path the bottom graph is a plot of the compass

readings vs. time where the red is the actual orientation and the blue is the compass output

---

---

Chapter 7

Basic System Operation

Figure 7.1: A field test being conducted in Amory Park

The Esplanade Runner is a project designed to allow any user to run the system with ease

and confidence. Its user-friendly applications are meant for a quick and speedy process so that

less time is spent setting the system up, and more time is spent watching the vehicle effortlessly

drive through the path you create.

41

---

42

CHAPTER 7. BASIC SYSTEM OPERATION

Before you get started, you will need the following items in order to run the Esplanade

Runner:

1. The Esplanade Runner

2. Computer with internet running Mozilla Firefox (Download for free at Mozilla.com)

3. Computer must also have SD memory card slot.

(a) SD memory card

We will now take you step by step through the execution process of the Esplanade Runner.

1

Site Selection

The Esplanade Runner will operate anywhere where there is GPS coverage. For it to accurately

maneuver through the route, however, there must be a clear open view of the sky so the GPS will

get the best sky coverage. Examples of this are big open fields, or parking lots. Tall buildings

do affect GPS coverage so places that are surrounded by tall buildings will not be ideal for the

Esplanade- Runner to operate. The GPS′s displayed accuracy should be less than 40 feet for

optimal operation. Tests have also shown that buildings with steel reinforced structures and

parking lots with parked cars proved to be poor operation sites. It is advised that the chosen site

have a minimal steel presence and other structures that may emit a substantial electromagnetic

field (cell phone towers, power lines). All of these things are known to disrupt the accuracy of

the compass chipset.

2

Route Drawing

Once you have Mozilla Firefox up and running, proceed to the web tool at:

http://people.bu.edu/skicavs/mapdraw4.html This website by default will take you to a satellite

view of the Boston University campus. To find your desired location simply click the mouse on

the map and drag it in any direction until you find the area you are looking for. To zoom in

and out, use the zoom tools in the upper left corner of the screen.

Before you start drawing your route, create a new text file and save it to a location you

will be able to find easily.

Once you decide where you want to your path to be, Single click the right mouse button

on the start point and drag the mouse along the route you choose to create. When completed,

click the mouse again and this will be your finish point. If you do not like your path, you can

simply click Clear on the right side menu and you can start over. You may also delete individual

waypoints on your route by clicking Delete for the corresponding waypoint on the map in this

menu.

When you are satisfied with your route, click on Export from the right side menu. A pop-up

window will appear with the waypoint coordinates. Select all by highlighting everything in the

---

3. LOADING PDA

43

window, and then right click to copy. Paste this into the text file you created, and save it as

(file name).gpx. The .gpx extension is necessary for the PDA to recognize this file and read it

as the appropriate file attachment.

3

Loading PDA

The next step in the setup is to get the waypoint file (the .gpx file you created) onto the PDA.

Insert the SD memory card into the computer and drag the .gpx file onto the memory card.

When the file is on the card, eject the card from the computer, and put it into the PDA SD

slot.

4

Running the Esplanade Runner

You are now ready to start the Esplande-Runner. To boot the system:

1. Power on the PDA via the power button at the top of the PDA.

2. Turn on the vehicle by flicking the silver switch up on the side of the vehicle so you see a

green light illuminate.

3. Power on the MCU by switching the switch on the MCU to the on position.

From the start menu on the PDA, open Programs File Explorer, and select EspRunner.

This is the application that runs the system.

To adjust the vehicle settings (see Figure 7.2) :

Debug Set Parameters

Parameter

Value

Mag offset

0

Left Max Speed

1300

Right Max Speed

1300

Forward Max Speed

900

GPS Sampling Time (ms)

1000

Logging

True

Obstacle Avoidance

True

Once you set the parameters, click APPLY, then Close

To load your route click: GPX Load GPX file (navigate to the saved route on your SD

card and click OK)

If the correct route is loaded click:

GPX Read Point

---

44

CHAPTER 7. BASIC SYSTEM OPERATION

Figure 7.2: Parameter Screen on EspRunner application running in PDA emulation environment

Then when you are ready to have the vehicle begin navigation

GPX Start Navigation

To properly terminate navigation

Debug Halt Navigation

To ensure a clean vehicle shutdown, always turn the vehicle off before turning the MCU

off.

5

Issues

If the vehicle starts rotating in circles or if the vehicle seems to be unresponsive:

If the vehicle spontaneously starts rotating in circles, or appears to be driving in a straight

---

5. ISSUES

45

line for too long, it is most likely due to compass failure. If this occurs you must reset the

compass. To do this you must first turn the vehicle power off, and then turn the MCU off. Once

both are off, then turn the vehicle back on first and then turn the MCU on. This will reset the

compass and the vehicle should resume route traversal.

If the PDA freezes:

If the PDA suddenly freezes up, this could be due to improper termination of the program.

To fix this, you must reset the entire system. Start by turning off the vehicle, and then turn off

the MCU. You will then have to manually reset the PDA, via a small reset button hole on the

left side of the PDA. Once the PDA is back on, refer to Section 4 (Page 43).

---

---

Appendix A

Component Specification Sheets

47

---

48

APPENDIX A. COMPONENT SPECIFICATION SHEETS

1

Garmin eTrex PDA Specifications

Position format

Lat/Lon, UTM/UPS, Maidenhead, MGRS

GPS performance

Receiver

12 parallel channel GPS receiver continuously

Acquisition times

Warm

Approximately 15 seconds

Cold

Approximately 45 seconds

AutoLocate

Approximately 5 minutes

Update rate

1/second, continuous

GPS accuracy

Position

< 15 meters, 95% typical*

Velocity

0.05 meter/sec steady state

Dynamics

6gs

Interfaces

RS232 with NMEA 0183, RTCM 104 DGPS

data format and proprietary GARMIN

Antenna

Built-in patch

Power Source

2 AA batteries (not included)

Physical Size

4.4"H x 2.0"W x 1.2"D (11.2 x 5.1 x 3.0 cm)

Weight

5.3 ounces (150 g) with batteries

Display

2.1"H x 1.1"W (5.4 x 2.7 cm) high-contrast

LCD with bright backlighting

Case

Waterproof to IEC 60529 IPX7 standards

Temperature range

5F to 158F (-15C to 70C)

More information at: https://buy.garmin.com/shop/shop.do?cID=144&pID=6403

---

2. CMPS03 MAGNETIC COMPASS CHIPSET

49

2

CMPS03 Magnetic Compass Chipset

Voltage:

5V

Current:

20mA Typ.

Resolution:

0.1 Degree

Accuracy:

3-4 Degrees approx.

Output 1:

Timing Pulse

Output 2:

I2C Interface, 0-255 and 0-3599

SCL Speed:

up to 1MHz

Weight:

0.03oz

Size:

32mm x 35mm

More information at: http://www.robot-electronics.co.uk/htm/cmps3tech.htm

---

50

APPENDIX A. COMPONENT SPECIFICATION SHEETS

3

MMP-8 Mobile Robot Platform

Length x Width x Height:

15.25 in x 12.5 in x 4.25 in

Weight:

7.5 lb.

Payload:

7 lb. additional

Body Style/Chassis

Aluminum, black anodized:

Drive Type:

6-Motor, 6-wheel drive, differential

Motor Details:

12V Gearhead motors, all metal gears

Wheel Details:

4.25. Diameter foam filled all-terrain tires

Steering:

Tank steer, differential type, zero turning radius

Speed:

3.7 ft./sec.

Suspension:

Tube suspension allows the robot to rotate independently

Tires:

Foam filled semi-pneumatic tires

Control

Controller details:

Custom High Current Motor drivers

with thermal and over current protection.

Motor drivers can be controlled with a

standard Hobby-type PWM signal

or with RS-232 serial control.

6-50 Volt, 10 amp continuous

Power

Battery (included):

Yes

Battery details:

12 V NiCad Rechargeable, 1400 mAh

Run Time:

Over 1 hour continuous running

Charger Included:

No

Recommended Charger:

6-12 V Universal Smart Charger

More information at: http://www.themachinelab.com/MMP-8.html

---

4. SRF05 ULTRA SONIC RANGER

51

4

SRF05 Ultra Sonic Ranger

Voltage:

5V

Current:

4mA Typ.

Frequency:

40KHz

Maximum Range:

4m

Minimum Range:

1cm

Max Analog Gain:

Variable to 1025 in 32 steps

Connection:

Positive TTL level signal, width proportional to range

Echo:

Multiple echo

Units:

uS, mm, or inches

Weight:

0.4oz

Size:

43mm x 20mm x 17mm

More information at: http://www.robot-electronics.co.uk/htm/srf05tech.htm

Figure A.1: The Acoustic Sensor′s Beam Profile

---

52

APPENDIX A. COMPONENT SPECIFICATION SHEETS

5

M68DEMO908GB60 MCU Board

· Evaluation board with a 60K Flash MC9S08GB60 MCU, dual DB9 RS232 serial ports,

switches, LEDs, MCU pin-breakout header and small prototype area

· Powered by two AA batteries (included) or optional external power supply

· Learn the HCS08 MCU Family quickly with demonstration code including A/D, timer,

PWM and keyboard interrupt routines

· Modify demo code or develop new code for the GB60 using free CodeWarrior Development

Suite for HCS08, Special Edition

· Program and debug code using free CodeWarrior Development Studio for HCS08, Spe-

cial Edition, through DB9 serial port and included RS232 serial cable or optional BDM

Multilink

More information at:

http://www.freescale.com/webapp/sps/site/prod summary.jsp?code=M68DEMO908GB60

---

6. HEWLETT PACKARD IPAQ RX1955 PDA

53

6

Hewlett Packard iPAQ RX1955 PDA

Device type:

Handheld PC

Display:

3.5" TFT Active Maxtrix screen with 16-bit color

Wireless:

Integrated 802.11b wireless LAN

Operating System:

Microsoft Windows Mobile 5.0 Premium operating system

Display size:

2.5 inches

Display color support:

16-bit

ROM:

64 MB

RAM:

32 MB

Data link protocol:

IrDA, IEEE 802.11b

Input device:

Touch-screen, 5-way joystick, Stylus

GPS:

None

Processor:

Samsung SC32442 300MHz Processor

Expansion:

Integrated SD slot

Battery type:

1100 mAh Lithium ion

Height:

4.5 inches

Depth:

0.6 inches

Width:

2.8 inches

Weight:

4.4 lbs

More information at: http://h71016.www7.hp.com/html/interactive/rx1955/model.html

---

54

APPENDIX A. COMPONENT SPECIFICATION SHEETS

7

GPS TEXT Output Communication Format

Taken From : http://www8.garmin.com/support/text out.html

------------------------------------------------------------

Simple Text Output Format:

The simple text (ASCII) output contains time, position, and velocity data in

the fixed width fields (not delimited) defined in the following table:

FIELD DESCRIPTION:

WIDTH:

NOTES:

----------------------- ------- ------------------------

Sentence start

1

Always ′@′

----------------------- ------- ------------------------

/Year

2

Last two digits of UTC year

| ----------------------- ------- ------------------------

| Month

2

UTC month, "01".."12"

T | ----------------------- ------- ------------------------

i | Day

2

UTC day of month, "01".."31"

m | ----------------------- ------- ------------------------

e | Hour

2

UTC hour, "00".."23"

| ----------------------- ------- ------------------------

| Minute

2

UTC minute, "00".."59"

| ----------------------- ------- ------------------------

\Second

2

UTC second, "00".."59"

----------------------- ------- ------------------------

/Latitude hemisphere

1

′N′ or ′S′

| ----------------------- ------- ------------------------

| Latitude position

7

WGS84 ddmmmmm, with an implied

|

decimal after the 4th digit

| ----------------------- ------- ------------------------

| Longitude hemishpere

1

′E′ or ′W′

| ----------------------- ------- ------------------------

| Longitude position

8

WGS84 dddmmmmm with an implied

P |

decimal after the 5th digit

o | ----------------------- ------- ------------------------

s | Position status

1

′d′ if current 2D differential GPS position

i |

′D′ if current 3D differential GPS position

t |

′g′ if current 2D GPS position

i |

′G′ if current 3D GPS position

o |

′S′ if simulated position

n |

′_′ if invalid position

| ----------------------- ------- ------------------------

| Horizontal posn error

3

EPH in meters

---

7. GPS TEXT OUTPUT COMMUNICATION FORMAT

55

| ----------------------- ------- ------------------------

| Altitude sign

1

′+′ or ′-′

| ----------------------- ------- ------------------------

| Altitude

5

Height above or below mean

\

sea level in meters

----------------------- ------- ------------------------

/East/West velocity

1

′E′ or ′W′

|

direction

| ----------------------- ------- ------------------------

| East/West velocity

4

Meters per second in tenths,

|

magnitude

("1234" = 123.4 m/s)

V | ----------------------- ------- ------------------------

e | North/South velocity

1

′N′ or ′S′

l |

direction

o | ----------------------- ------- ------------------------

c | North/South velocity

4

Meters per second in tenths,

i |

magnitude

("1234" = 123.4 m/s)

t | ----------------------- ------- ------------------------

y | Vertical velocity

1

′U′ (up) or ′D′ (down)

|

direction

| ----------------------- ------- ------------------------

| Vertical velocity

4

Meters per second in hundredths,

\

magnitude

("1234" = 12.34 m/s)

----------------------- ------- ------------------------

Sentence end

2

Carriage return, ′0x0D′, and

line feed, ′0x0A′

----------------------- ------- ------------------------

If a numeric value does not fill its entire field width, the field is padded

with leading ′0′s (eg. an altitude of 50 meters above MSL will be output as

"+00050").

Any or all of the data in the text sentence (except for the sentence start

and sentence end fields) may be replaced with underscores to indicate

invalid data.

---

---

8. MCU INTERNAL SCHEMATIC

57

8

MCU Internal Schematic

---

---

Appendix B

Specification Discussion

The accuracy of the system was originally specified to stay within 20 feet of the desired route.

With optimal GPS conditions that enabled good satellite coverage however, the vehicle was

tested to stay in a 5-10 foot buffer range on each side of the desired route.

The operation time as tested was limited to 40 minutes of use. In the system specifications

however, it states that the vehicle should operate for no less than one hour. The shortage of time

between the system specification and the specification as tested is due primarily to the speed at

which the vehicle moves. At higher speeds, the motors require more power, which depletes the

battery at a quicker rate.

Unlike the system specifications that suggested the vehicle could only traverse through

concrete and short grass surfaces, the mobile platform is an extremely rugged and maneuverable

vehicle. It was tested in a variety of terrain conditions and has proven the ability to navigate

through virtually any terrain excluding anything with water. The only limitation the vehicle

poses is there can not be an increase in inclination of more than 20 degrees due to compass

orientation failures.

The compass orientation failures that occur at inclinations of greater than 20 degrees are

cause by manufacturer design specifications and could not be altered.

Originally the specification required by the customer in this project was that the vehicle had

to avoid obstacles greater than 20 cubic centimeters. Throughout testing however, we discovered

that the acoustic sensors can be very sensitive and are able to identify objects as small as 15

cubic centimeters for the vehicle to navigate around.

In the original design of the system, the GPS was specified to spit out an NMEA string of

data in which the PDA would parse and gather the appropriate information from. It was later

realized that the GPS unit had a similar function to spit out a string of TEXT format data

in one line. This output was more ideal than the NMEA because it would be more efficient to

send along to the PDA via the MCU. There was also clear output format to follow that made it

simple for the PDA to parse and obtain the appropriate data regarding longitude and latitude

coordinates.

59

---

---

Appendix C

Future Steps

Since this project is meant to be a legacy project this section was made as an area to specifically

point out shortcomings in the project that either we or our customer have identified that we

were unable to fix in the timeframe of this year

1

RouteDraw Web Tool

The RouteDraw tool while mostly function at this point certainly has quite a few possibilities

for improvement

· Explore Internet Explorer 6 incompatibility to determine the cause and fix. Also test with

more browsers such as Opera or the KDE browser, possibly even mobile internet browsers

· Use a real webserver and setup MIME so that the user can download the GPX file instead

of the current copy and paste method

· Develop a plug-in to work with ActiveSync to allow the route to be copied directly from

the site to the PDA

· Allow the program to read in a GPX file and let the user edit that file

· Write a routine to allow for easy map printing

61

---

---

Glossary

ActiveSync

The technology developed by Microsoft for

61

syncing information with Windows Mobile

and Windows CE based devices. We use this

in the project to copy the application and

route files onto the PDA

Google Maps API

The Google Maps API provides an interface

32

to a worldwide spatially correlated database

of maps around the world. It also provides

the tools to easily navigate these maps and

draw lines or points on them. It is very sim-

ilar to the Yahoo, and Microsoft Map API′s

but currently the performance and function of

Google is best

GPX

GPX is the XML-based file format stan-

32

dard for storing gps data such as waypoints,

tracks, and routes. We use this format be-

cause a number of other programs read and

write this format and the standard is open

rather than KML which is Googles propri-

etary standard for Google Earth. The spec-

ifications for this standard can be found

http://www.topografix.com/GPX/ 1/1

HDOP

Horizontal Dilution of Precision is the term

16

calculated on the GPS unit that estimates the

accuracy of the GPS unit from the number of

satellites, the quality of the signal, and a va-

riety of other complex factors. This number

can easily be read from the GPS ′s LCD but

this information is used only as a rough in-

dication of site feasibility (the more satellite

fixes the unit has, the greater the accuracy.

63

---

64

Glossary

I2C

This is the serial communication standard

13

used for the interaction between the Compass

and the MCU

NMEA

National

Marine

Electronics Association:

10

This represents the standard in GPS output

formatting. Although our project no longer

uses this format, the format we currently use

is very similar although is only a standard by

Garmin format

PWM

Pulse Width Modulation is the method used

13

for the MCU to communicate with the plat-

form. The idea behind PWM is that a pulse

train is sent along the data line and each

of these pulse has a slightly different width.

The information in the signal is contained

by the width of the pulse.

For example

with our setup there is a center width of the

pulse which corresponds to the motors being

stopped. If you increase the width the mo-

tors begin to go forward if you decrease the

width they go in reverse. For our setup there

are two data lines one going to the left bank

of motors and one going to the right bank of

motors

TEXT Format

The TEXT format is a standard developed by

54

Garmin for output from their GPS units. The

output is much more efficient for our project

than the NMEA strings since in TEXT ev-

eryline contains the same information rather

than having to wait for every 4th line

---

Index

ActiveSync, 61

CodeWarrior, 22

GPS, 9, 48

HDOP, 16

TEXT, 10

GPX, 32, 61

JavaScript, 32

MCU, 52

I2C, 7, 14

PWM, 7, 14, 21

PDA

C#, 27

Windows Mobile, 27

Platform

MMP-8, 50

Power Systems, 17

Sensors

Acoustic, 51

Compass, 14, 49

65

---