Design of Sensor and Wireless Data Acquisition

System For Field Testing of Hull Models

by

Douglas John Guardino

Bachelor of Science Ocean Engineering

Florida Institute of Technology 2004

A thesis submitted to the College of Engineering at

Florida Institute of Technology in partial fulfillment of the requirements

for the degree of

Masters of Science in

Ocean Engineering

Melbourne, Florida July, 2004

We the undersigned committee hereby approve the attached thesis

Design of Sensor and Wireless Data Acquisition System For Field Testing of Hull Models

by

Douglas John Guardino

________________________________ Eric D. Thosteson, Ph.D., P.E. Assistant Professor Ocean Engineering and Oceanography ________________________________ Andrew Zborowski, Ph.D. Professor and Program Chair Ocean Engineering ________________________________ Hector Gutierrez, Ph.D., P.E. Associate Professor Mechanical Engineering

Abstract Title : Design of Sensor and Wireless Data Acquisition System

For Field Testing of Hull Models

Author: Douglas John Guardino

Committee Chair: Eric D. Thosteson, Ph.D., P.E.

This paper describes the design and testing of a group of sensor and

communication systems based on Microchip’s PIC family of microcontrollers.

Analog and digital sensor data is read using multiple microcontrollers networked

using I2C. An iinChip module interfaced to the sensor systems allows data to be

sent from a remote location using TCP/IP and wireless Ethernet (802.11b). The

paper also describes a motor control system designed for use on a model hull

known as the LOMAC. These systems were designed to be implemented on the

LOMAC model to reconstruct the motions of the model hull under natural wave

conditions.

The sensor systems have successfully gathered data from a variety of sensors

including GPS, a digital compass, accelerometers, and an inclinometer. The

system is remotely accessed over the wireless Ethernet connection using Telnet,

providing data at near real-time. During testing it was found that the

iii

accelerometers performed with approximately a 0.04G noise band, with hard

motions being readily apparent in the data record. It was also found that the

inclinometer responds to the acceleration as well as static tilt, which will require

post-processing for interpretation. The results indicate that much of the analog

data would benefit from additional signal conditioning.

iv

Table of Contents ABSTRACT..................................................................................................................................III TABLE OF CONTENTS...............................................................................................................V LIST OF FIGURES ................................................................................................................... VII LIST OF TABLES ....................................................................................................................VIII ACKNOWLEDGEMENT........................................................................................................... IX DEDICATION................................................................................................................................X 1.0 INTRODUCTION....................................................................................................... 1

1.1 GOALS ........................................................................................................................... 1 1.2 BACKGROUND................................................................................................................ 2

1.2.1 LOMAC .................................................................................................................... 3 1.2.2 Wireless Data Acquisition ........................................................................................ 5 1.2.3 TCP/IP Communications Overview........................................................................ 13 1.2.4 Pic Basic Pro and PIC C18.................................................................................... 15

1.3 SCOPE .......................................................................................................................... 17 2.0 SYSTEMS.................................................................................................................. 19

2.1 LOMAC DRIVE SYSTEMS............................................................................................ 19 2.1.1 LOMAC Motor Driver............................................................................................ 20 2.1.2 R/C Interpreter ....................................................................................................... 23

2.2 DATA ACQUISITION AND COMMUNICATION SYSTEMS ................................................. 26 2.2.1 GPS Reader ............................................................................................................ 28 2.2.2 Inclinometer System................................................................................................ 30 2.2.3 Digital Compass ..................................................................................................... 33 2.2.4 Accelerometers ....................................................................................................... 34 2.2.5 IIM7010A................................................................................................................ 39 2.2.6 PICNIC................................................................................................................... 41

3.0 TESTING AND RESULTS ...................................................................................... 46 3.1 FALL 2003 POOL TEST ................................................................................................. 46 3.2 SPRING 2004 POOL TEST.............................................................................................. 47 3.3 CAR TEST 1 .................................................................................................................. 49 3.4 CAR TEST 2 .................................................................................................................. 52 3.5 CAR TEST 3 .................................................................................................................. 56 3.6 ENGINE POWER TEST ................................................................................................... 60

4.0 DISCUSSION ............................................................................................................ 63 5.0 CONCLUSIONS AND RECOMMENDATIONS .................................................. 71 REFERENCES............................................................................................................................. 75 APPENDIX A: LOMAC MOTOR DRIVE CODE................................................................... 77 APPENDIX B: R/C INTERPOLATOR CODE......................................................................... 81 APPENDIX C: GPS READER CODE....................................................................................... 85

v

APPENDIX D: INCLINOMETER SLAVE CODE .................................................................. 89 APPENDIX E: PICNIC CODE................................................................................................... 92 APPENDIX F: MOTOR DRIVER SCHEMATIC.................................................................. 109 APPENDIX G: R/C INTERPOLATOR SCHEMATIC ......................................................... 110 APPENDIX H: POWER AND GPS BOARD SCHEMATIC................................................. 111 APPENDIX I: ACCELEROMETER BOARD SCHEMATIC .............................................. 112 APPENDIX J: PICNIC BOARD SCHEMATIC..................................................................... 113 APPENDIX K:FLORIDA TECH CAMPUS ........................................................................... 114 APPENDIX L: BOAT TEST - ACCELERATION DATA..................................................... 115 APPENDIX M: CAR TEST 1 – ACCELERATION............................................................... 116 APPENDIX N: CAR TEST 1 - ACCELERATION AND INCLINOMETER...................... 117 APPENDIX O: CAR TEST 2 - ACCELERATIONS AND INCLINATION ........................ 118 APPENDIX P: CAR TEST 3 - ACCELERATION AND INCLINATION........................... 119

vi

List of Figures Figure 1.1: LOMAC Model Hull ............................................................................ 3 Figure 1.2: System Block Diagram......................................................................... 4 Figure 2.1: LOMAC Drive System Diagram........................................................ 19 Figure 2.2: LOMAC Jet Drive System ................................................................. 20 Figure 2.3: Motor Driver Board............................................................................ 22 Figure 2.4: Data Acquisition and Communication System .................................. 26 Figure 2.5: Sensor System Board Diagram........................................................... 27 Figure 2.6: GPS Reader System Diagram............................................................. 28 Figure 2.7: RMC NMEA Tag Definition (NMEA, 2004) .................................... 29 Figure 2.8: Inclinometer System Diagram............................................................ 30 Figure 2.9: Quadrature Signal............................................................................... 31 Figure 2.10: Digital Compass System Diagram ................................................... 33 Figure 2.11: Heading Geometry ........................................................................... 34 Figure 2.12: Microchip Instrumentation Amplifier (Microchip, 2004)................ 37 Figure 3.1: Boat Test - Acceleration Data ............................................................ 48 Figure 3.2: Car Test Vehicle................................................................................. 49 Figure 3.3: Florida Tech Campus ......................................................................... 50 Figure 3.4: Car Test 1 – Acceleration................................................................... 51 Figure 3.5: Car Test 1 - Acceleration and Inclinometer ....................................... 52 Figure 3.6: Car Test 2 - GPS Path......................................................................... 53 Figure 3.7:Car Test 2 - Accelerations and Inclination.......................................... 54 Figure 3.8: Car Test 2 - Heading .......................................................................... 55 Figure 3.9: Car Test 2 - GPS Speed...................................................................... 56 Figure 3.10: Car Test 3 - GPS Path....................................................................... 57 Figure 3.11: Car Test 3 - Acceleration and Inclination ........................................ 58 Figure 3.12: Car Test 3 - Speed ............................................................................ 59 Figure 3.13: Car Test 3 - Heading ........................................................................ 60 Figure 3.14: Motor Current - unloaded................................................................. 61 Figure 3.15: Motor Current with Drive Train....................................................... 62 Figure 4.1: Motor Driver and Fan......................................................................... 64

vii

List of Tables Table 2.1: Conversion Times................................................................................ 36 Table 2.2: IIM7010A Settings .............................................................................. 41

viii

Acknowledgement I would like to acknowledge the following individuals and companies for their contributions to this project: Dr. Eric Thosteson for being my advisor and committee chair, for providing technical information and help troubleshooting problems. Dr. Andrew Zborowski for introducing me to the LOMAC project and providing insight and advice about the project. Dr. Hector Gutierrez for teaching me about the functions of the PIC microcontroller and providing insight and advice about the project. Dr. Stephen Wood for providing support for learning C18. Bill Battin for providing advice, options and construction help. Mark Cencer, Travis Burland, and Patrick Hatton for constructing the LOMAC. Eduardo Gonzales for continuing to work and improve the LOMAC, construction help, and testing help. Dr. Brian Howell for providing advice and sharing a work space and supplies. Florida Tech’s University Publications for use of the use of the campus map. Microchip, Texas Instruments, Maxim Semiconductor, Analog Devices for providing free samples of their products. Wiznet for creating the IIM7010A, making TCP/IP and Ethernet communications simple. Without these individuals and companies this project would never have been realized.

ix

Dedication

To my family who supported me.

x

1.0 Introduction With emerging technology, researchers desire to obtain their sensor data faster

and to make remotely acquired data available over longer distances. In the past,

the data needed to be logged on a data logger and downloaded later, or a computer

had to be directly connected to the sensor. For fast access to remote data, costly

proprietary radio modems were employed. This is changing with the prevalence

of the Internet, the trend making everything Internet-enabled, and the introduction

of wireless Ethernet with its drastic cost reductions.

1.1 Goals The goal of this thesis is to design, implement, and test a remote, wireless, nearly

real-time sensor and data acquisition system for evaluation of the performance

characteristics of a boat. To evaluate the performance characteristics of the boat

the acceleration in 3 axes the heading, the pitch, roll, speed, and location. This

microcontroller-based system design is modular, so it can be implemented in

other applications. The communications system will be based on the TCP/IP

communication protocol and will run on 802.11 and 802.3 Ethernet hardware.

The TCP/IP protocol was chosen because of its prevalence in the world today.

Ethernet was chosen as the hardware to use, since the introduction of 802.11

1

wireless Ethernet allows transmission of data over moderate distances quickly,

easily and inexpensively. The processor that will be used is from the PIC family

of microcontrollers made by Microchip, Inc. Firmware for the microcontrollers is

written in a combination of BASIC and C. In the following work, the combined

implementation of these technologies, termed the PICNIC system, is described.

1.2 Background The systems described are not new they draw from the previous works of others

and currently available technologies. The boat (LOMAC) that the data collection

system is to be implemented on was built as part of a Marine Field Project by

Burland et al. Wireless data acquisition is not a new idea researches have been

utilizing in different forms for years but never in the way presented here. TCP/IP

communications is a technology that the internet is based on. During the course of

this project two different languages where used to program the PIC

microcontrollers; Pic Basic Pro and PIC C18.

2

1.2.1 LOMAC

Figure 1.1: LOMAC Model Hull LOMAC (Littoral-Operation Multipurpose Auxiliary Craft) catamaran was

designed by Andrew Zborowski to provide optimal stability in the littoral zone

(Burland, et al. 2002). The craft was designed to operate in the harsh wave

conditions found in the littoral region. Burland et al. built and tested a model of

the catamaran (

Figure 1.1). Using the sensor and data acquisition system described herein, this

model is going to be used to analyze the expected performance of the prototype

vessel in the littoral region. Characteristics to be analyzed are the hull motions

and maneuverability in wave conditions expected in the littoral region. This thesis

3

describes the PICNIC, an innovative sensor, data acquisition, and communication

system which allows this data to be obtained in near real-time. Two 3-axis

accelerometers, two inclinometers, and a compass will provide data needed to

reconstruct the motions of the vessel. A GPS will provide location, speed and

rough heading. Data from these sensors is transmitted from the model to a remote

PC over a wireless TCP/IP network as seen in Figure 1.2.

Figure 1.2: System Block Diagram

4

1.2.2 Wireless Data Acquisition Wireless data acquisition is not a new idea, however the combination of

technology being used in the PICNIC system is new. In previous systems

described in the literature, PIC and other microcontrollers have been used for data

collection and wireless Ethernet has been used for data communication. Only

recently has the integration of the two technologies been made possible. Several

different configurations were found in a review of recent papers on wireless data

acquisition.

Hamel et al. (2002) used a PIC microcontroller and RF transmitters to collect

data. Their goal was to create a scalable network of sensors using TDMA (Time

Division Multiple Access) networking. In this application they have several

sensors that wake up and wait for random periods of time before transmitting a

packet of data to a SBC (single board computer). The SBC checks the integrity of

the communication, since more than one node can potentially transmit at the same

time. The integrity is checked by comparing the checksum in the packet with that

computed on the receiving end. If they don’t match, the system discards the

information. This system was designed for low speed acquisition. The example

presented had an acquisition interval of 5 minutes with 100 nodes and had a data

loss of 10% from rejected information. The data stored on the SBC can be

accessed via multiple techniques: over an Ethernet network, cell phone or a

5

conventional phone line. The data on the SBC is available in several formats,

including HTML, XML, or comma delimited text. The data needs to be offloaded

periodically, since upon filling the data storage space, the system will stop

logging and preserve the already collected data. The SBC has a storage capacity

of only 128 Kbytes. The system can transmit data in intervals as low as one

second and collect it at a rate of 200 Hz (Hamel, 2002).

In this system, it is likely that data loss would increase with shorter transmission

intervals due to a greater chance of collision from two transmissions occurring in

the same time frame. This is a potential problem since the system includes no

mechanism to recover lost data. Another limitation of this system is the small data

storage capacity, since new data is rejected after reaching capacity.

Adcock et al. (2001) use a microcontroller and an RF modem to transmit data

back to PC. Their system was designed to replace the traditional data acquisition

system used in a wind tunnel. The goals of this system were to reduce error and

noise in the system by removing alternate load paths and removing long sensor

leads. Traditionally the sensors in the test model were connected via long wires to

the data collection system. These wires provided alternate load paths inducing

error in the loading readings. The length of the wires needed to connect to

equipment outside the wind tunnel resulted in an increase in the amount of noise

6

introduced into the readings. Antenna placement is a concern, because some

models made of metal require an external antenna that won’t modify the

aerodynamics (Adcock, 2001).

This is a good example of how RF modems have been used with microcontrollers

to acquire data wirelessly. This is a good example of how wireless technology can

be used to improve existing data acquisition situations.

Lohachit et al. (2003) describe a system that uses a PC104 stack and a RF modem

to collect water quality data from a remotely controlled boat. The system collects

water quality, depth, compass heading and GPS data. This data is transmitted real

time back to a PC for logging. The boat is controlled by an R/C controller and has

proximity sensors to alert the operator of collision hazards. The PC/104 on the

boat runs Linux. A digital compass is used in the system to backup the GPS since

the GPS will only provide heading data while the boat is moving. This system can

be used to map the water quality and contour of a shallow water environment

(maximum depth of 3 feet and a minimum of 6 inches). The boat that caries the

system is 7 feet long and 3 feet wide and is powered by a 12 volt trawling motor

interfaced to an R/C controller. Their RF modem provides a 900 meter operating

range, but the boat is also limited by the operator’s line of site (Lohachit, 2003).

7

This is the closest example found in the literature to the PICNIC system in

application. It gathers data in a similar way; it collects data remotely and sends it

back to a PC to log it. This system is also mounted on a boat that is driven by an

R/C controller, like the LOMAC.

Mitchell, et al. describe a system consisting of a cluster of sensors that pass data

to a central cluster, which further communicates to an outside system using a

cellular modem. This system was designed to be a low cost system for use in

monitoring the “health” of a structure, like an airplane’s airframe. Requirements

for the sensors included the need to occupy a small amount of space and to use a

small amount of power. The sensors are based on Cygnal’s system on chip,

communicate using Bluetooth, and can pass data from each other to the central

cluster. According to the official Bluetooth membership site,

The Bluetooth wireless specification defines a low-power, low-cost technology that provides a standardized platform for eliminating cables between mobile devices and facilitating connections between products. … Radios that comply with the Bluetooth wireless specification operate in the unlicensed, 2.4 GHz radio spectrum ensuring communication compatibility worldwide. These radios use a spread spectrum, frequency hopping, full-duplex signal at up to 1600 hops/sec. The signal hops among 79 frequencies at 1 MHz intervals to give a high degree of interference immunity.”(Bluetooth.org, 2004)

The central cluster is a PC104 system running Windows. It uses Bluetooth for

communications with the sensors and a cellular modem for communications to a

8

PC. The PC functioned as a web server, so the data could be accessed via the

Internet. This was a culmination of several iterations of the system. During the

iterations they came up with error checking and communication protocols of their

own to facilitate the data transfer. Since the PC104 system has a hard drive it is

tolerant to a loss of the cellular connection. It can buffer the data during a

connection loss, reconnect and upload all the buffered data (Mitchell, 2002).

Mitchell et al. presented many different technologies that can be used in wireless

data acquisition but didn’t make use of Wireless Ethernet, possibly due to the low

power requirements of the final design. This system illustrates the complexity in

ensuring data integrity when developing a communication protocol.

Edward’s describes (1998) a system of two PC104 computers that are connected

back to a central monitoring system via a cellular modem. The system was

designed for analysis and monitoring potential failure of a design in field

conditions. One of the goals was to design a system that required no human

interaction. Another goal was to create a system that could withstand harsh

conditions. The communication system needed to be able to operate in a variety of

locations across the county. Several cellular and satellite options were explored

for feasibility, availability and cost. Analog cellular was chosen because of

geographical area covered and the low cost of implementation. Each of the PC104

9

systems had different functions. One was responsible for collecting the data and

the other for handling the communication with the central monitoring system. The

two PC104 computers were connected together using Ethernet networking. The

system had the ability to gather many types of data including GPS, digital vehicle

data, and analog values like strain. Data was transmitted back to the home base at

timed intervals, cellular connection permitting (Edward, 1998).

This system had a great number of applications and had the capacity to gather

large amounts of data. The system utilized cellular communications to give it a

large coverage area, which creates a more mobile system, but incurs monthly

service and air time charges. The system is a slightly over-powered and costly due

to the use of two PC104 systems. Much of the data collection could have been

handled by microcontrollers, as seen in other papers.

Raygan and Callahan (2004) review data acquisition capabilities of currently

available computing systems and 802.11b for wireless remote data acquisition.

They review the capabilities of various interface types, like USB, USB 2.0,

FireWire, IEEE 488, Ethernet, and PCMCIA. The paper recommends using Linux

as the operating system since it is open source and therefore low cost. Several

platforms for central processing are examined including the PC, a PDA (personal

digital assistant) and a SBC (single board computer). It was proposed that by

10

storing of the downloaded data in a database and using SQL (structured query

language), the data could be manipulated to produce the desired output. They

suggest that in order to preserve data integrity, raw data should not be altered and

the manipulated data should be stored in separate tables (Raygan, 2004).

While Raygan and Callahan present a good review of the capabilities of the

presented technology, it could have been more comprehensive, considering the

use of microcontrollers and operating systems other than Linux. The idea of using

a SQL database for management of the data was unique among the articles

reviewed.

In Winfield and Holland (2000), a group of robots are each controlled by the use

of an onboard 386SX CPU running Linux and communicate using a wireless

LAN. In this application, each system can be remotely monitored and modified by

use of a designed program. Each system is accessed by remotely logging-in via

Telnet to the Linux system running on the individual. Each robot is individually

accessible by its IP address. The paper compares TCP and UDP as protocols for

communications, and concludes that TCP is a better choice because of built-in

error control, preserving data integrity. It was observed that there was a latency of

3 to 6 ms between the external controller and the robots. For this reason, the low

11

level controls were handled onboard while higher level control operations could

be commanded from the external controller (Winfield, 2000).

The choice of the TCP protocol confirmed recommendations from other sources

The concept of multiple nodes accessed by IP could also be applied to a sensor

network.

Several previous endeavors using wireless technology for data acquisition have

been described. No instances were found which used 802.11 wireless Ethernet

technology with a microcontroller. RF modems were used when microcontrollers

were used. Instances where wireless Ethernet was implemented, PC-based

hardware was used. PC-based hardware also was connected using cellular and RF

modems. In the projects reviewed, the PC-based hardware had greater data

processing capabilities. The combination of a microcontroller and wireless

Ethernet technology is relatively new. This is likely due to the small amount of

data that is normally produced by a microcontroller - small compared to the

capacity of an 802.11 wireless network.

12

1.2.3 TCP/IP Communications Overview

According to Bentham, TCP/IP (Transmission Control Protocol/Internet

Protocol) communications is layered (Bentham, 2002). In this application,

Wiznet’s IIM7010A handles most layers of the stack, allowing the top layer,

application, to be the focus. When using TCP/IP on an Ethernet network, there are

several things that must transpire before the communication between the

machines may occur. In TCP/IP, network nodes are identified by IP addresses.

Communication is initiated between 2 nodes by a client node specifying the IP

addresses of the server node with which it wants to initiate communications.

Ethernet hardware doesn’t recognize these IP addresses. Ethernet was designed to

handle multiple protocols and has its own addressing scheme. These Ethernet

addresses are commonly know as MAC (Media Access Control) addresses, or

physical address. The MAC address is a 6-byte address that is unique to the

individual hardware component and is issued by IEEE to manufacturers. The

TCP/IP stack on one node sends out an ARP (Address Resolution Protocol)

packet. This packet is sent out to the network asking for the MAC address

corresponding to a particular IP address. Once the ARP returns with the correct

MAC, communications between the two nodes may begin.

13

In TCP/IP, communication ports are specific destination spots on the nodes; they

allow simultaneous use of several available services. The client and server both

must know from which port to expect the data. A great number of ports have been

standardized as the default ports for certain applications, i.e. Port 80 is used for

HTML requests. This means that by default, most web servers will be listening on

port 80 for HTML requests. If a web server is set up to listen on a non-standard

port, the web client must specifically request information from the proper server

port number.

TCP/IP communications can take two forms: UDP and TCP. UDP and TCP both

use an IP address and a port for communications. UDP is a simple way to transfer

data from one place to another using a small packet of data, but verification of

data receipt is included in this protocol. TCP communication is more complicated.

TCP communication includes data loss protection. It verifies that every packet of

information is received and resends unconfirmed packets. This makes TCP a more

reliable form of communication, but also requires greater overhead for

communications.

14

1.2.4 Pic Basic Pro and PIC C18 PIC microcontrollers are a FLASH based, allowing them to be programmed for

specific applications. PIC’s assembly language is not user friendly therefore

higher level languages were used in the development of the code for the PIC

microcontrollers used in this project. Two different languages, microEngineering

Labs’ Pic Basic Pro version 2.24a and Microchip’s PIC C18 version 2.30, were

used during the course of this project. Each language has advantages and

disadvantages.

Micro Engineering Lab’s Pic Basic Pro is a simple programming language. It

provides a great number of commands that can use the hardware peripherals of

the PIC, and additionally, it provides software based implementations of these

peripherals, extending the capabilities of the PIC. The use of these commands

provides many functions including I2C communication, USART communication,

standard LCD character display control, and Pulse Width Modulation, as well as

standard programming commands. Pic Basic Pro’s largest data element size is a

word (2 bytes) and it has no signed or floating point values. Pic Basic Pro is able

to handle arrays of data, but does not directly handle null terminated strings. The

greatest advantage of Pic Basic Pro is that it is not tied to a specific processor

family. It can be used with certain members of the 12 series, 16 series, 17 series,

and 18 series of PIC microcontrollers. Pic Basic Pro has two limitations when one

15

tries to create complex code. First, variables can not be passed to subroutines.

Second, it does not support the use of pointers. All memory allocation in Pic

Basic Pro is static. Interrupts in Pic Basic Pro are handled after the current

command finishes executing. This can be helpful, since interrupts are supported,

but can also cause latency problems depending on the execution time of the

command. Pic Basic Pro is ideal for the beginner programmer and good for

simple programs.

Microchip’s PIC C18 is an ANSI C based compiler. Unfortunately, it doesn’t

contain many of the standard libraries normally associated with a C compiler. The

main limitation of PIC C18 is that it will only work with the 18 series PICs. The

libraries that come with PIC C18 which support the PIC’s hardware peripherals

are limited in their functionality. The commands within these libraries only

manipulate registers, which is easily done without making use of the libraries. The

software based functions that mimicked hardware functionality of the PIC were

not used and therefore can not be evaluated. PIC C18 has three significant

advantages over Pic Basic Pro. First, variables can be passed to a subroutine.

Another advantage of PIC C18 is that it can dynamically allocate memory. This

complicates debugging, but it improves memory management. The same memory

locations can be reused by different functions. Finally, PIC C18 allows the use of

pointers. A pointer simplifies data manipulation, especially with larger data types.

16

PIC C18 supports a multitude of data types, ranging from signed or unsigned

characters, to double precision floating point numbers, to null terminated strings.

It has libraries for manipulation and creation of these strings. All of this

functionality makes PIC C18 an ideal compiler for complex program generation.

1.3 Scope Several systems were designed and implemented during the course of this

research for use with the LOMAC. The system has been implemented on several

stackable circuit boards using generic connections. Connections between boards

in the stack are made with an IDE cable that passes all of the relevant pins of the

PIC to the other boards. The cable also distributes power to most of the items on

the stack. The boards are the PICNIC board (communication), GPS/power board,

and accelerometer/sensors board. There is also a breakout breadboard which

provides the LCD screen connection and another PIC used to read the inclination

sensor. Motor drivers for the jet drive system in the LOMAC were also designed

and implemented. These motor drivers are controlled by an R/C interpreter board

that interprets an R/C receiver’s commands.

17

In the course of this research, these systems will be tested and evaluated. The data

produced by the PICNIC system will be presented in a discernable manner. The

power drawn by the motor controllers and engines will be analyzed.

18

2.0 Systems Within this research, there were several systems designed. There are two

categories of systems designed; the LOMAC drive systems and the sensor and

data acquisition / communication systems.

2.1 LOMAC Drive Systems

Figure 2.1: LOMAC Drive System Diagram

The drive system is composed of two parts; the motor driver and the R/C control

interpreter. The systems are controlled by a Futbar FP-R127DF FM receiver. The

initial design of the system assumed the boat could be steered by use of

19

differential powering - powering one engine more than the other. This assumption

would prove to be wrong.

2.1.1 LOMAC Motor Driver The LOMAC uses jet drives for propulsion Figure 2.2. This means that the motor

driver only needs to drive the motor in one direction since water jets operated in

reverse provide little propulsive force. The motor drivers were designed to use

PWM (Pulse With Modulation) to drive the motors, Hall Effect sensors to count

shaft rotations, and an onboard 555 timer as a time base. The motor drivers are

programmed in Pic Basic Pro and communicate with the R/C interpreter board

using I2C.

Figure 2.2: LOMAC Jet Drive System

20

I2C is an addressable two-wire synchronous serial communication protocol which

supports communication between multiple devices on the same bus. There are two

types of devices on the bus: the master and the slave devices. There can only be

one master on a bus, but there can be up to 128 slaves. Each slave device on the

bus has its own 7-bit address on the bus, also known as a control code. The slave

device only responds to commands incorporating its control code. Slave devices

can also have their own internal addressing schemes. From this point forward, all

bus addresses will be referred to as control codes and internal addresses will be

called addresses.

To use I2C communications, the motor driver board, Figure 2.3, was configured as

a slave device, as seen in the program listing in Appendix A: LOMAC Motor

Drive Code. The program for the slave communication checks both the I2C

control code and the address specified by the master. After receiving the control

code, the slave device receives the address of the variable from which the master

wishes to read or to which the master wishes to write. After the subsequent read

or write command, the slave device’s internal address is reset, expecting a new

address to be sent. This requires that the internal address be specified with each

access.

21

Figure 2.3: Motor Driver Board The specified motors require a nominal current of 12 amps at 12 volts. To provide

this power, a MOSFET was used to amplify the PWM signal from the PIC.

International Rectifier’s IRLBA3803 N – channel MOSFET was selected because

of its ability to function with continuous currents exceeding 100 amps and its

ability to handle 30 volts from drain to source. The current from the PIC is

insufficient to trigger this MOSFET at the desired frequency because of the high

gate capacitance of the MOSFET. MAXIM’s MAX4420 MOSFET driver takes

the logic signal from the PIC and provides sufficient current to drive the gate of

the MOSFET. The PWM signal the motor receives is now double buffered from

the PIC through the MOSFET and the MOSFET driver.

At present, the Hall Effect sensors are not installed, since pool-tests suggest that

the drive train of the LOMAC should be replaced. The Hall Effect sensors would

22

require a magnet to be attached to the drive shaft, with the Hall Effect sensor then

mounted adjacent to the magnet. The sensors can be installed after installation of

a new drive shaft. The connections for it are shown on the motor driver board

schematic (Appendix F: Motor Driver Schematic).

2.1.2 R/C Interpreter The motor driver boards are controlled by an R/C interpreter board (Appendix G).

The original idea was to steer the boat using differential power, changing the

relative power in one engine to create a turning moment acting on the ship,

eliminating the need for a rudder. The interpreter board receives two signals from

the receiver: intensity and a left/right differential, both signals being pulse length

modulated signals. The interpreter board currently uses a control algorithm

written in Pic Basic Pro, Listing 1, to convert the intensity to a PWM value. The

full version of the code used with the R/C interpreter is in Appendix B.

Listing 1: Control Algorithm

controlP = intensity received from the R/C receiver, range 108 -190 108 = minimum intensity 190 = maximum intensity controlD = differential received from the R/C receiver, range 108 – 190 108 = maximum left turn 190 = maximum right turn outdataL = power setting for left motor, range 0 – 255 0 = engine off 255 = engine fully on

23

outdataR = power setting for right motor, range 0 – 255 0 = engine off 255 = engine fully on setspeed is where the speed of the motors is sent to the individual motors. if controlP < 117 then

intensity = 0 outdataL = 0 outdataR = 0 goto setspeed

endif if controlP > 180 then

intensity = 255 goto checkdiff

endif intensity = (controlP - 117) * 4 checkdiff: if controlD < 149 then

outdataR = intensity if controlD < 103 then

outdataL = 0 goto setspeed

endif diff = (149 - controlD) * 5 if diff > intensity then

outdataL = 0 else

outdataL = intensity - diff endif goto setspeed

endif if controlD > 151 then

outdataL = intensity if controlD > 192 then

outdataR = 0 goto setspeed

endif diff = (controlD - 151) * 6

if diff > intensity then

outdataR = 0 else

outdataR = intensity - diff endif

24

goto setspeed

endif outdataR = intensity outdataL = intensity setspeed:

The program then checks the differential signal. If there is need for a differential

adjustment, then the controller slows down one motor by a bounded linear

algorithm. These values are then sent to the motors. The algorithm does not

process the intensity and differential if there is no change in their values; this

reduces processor overhead and unneeded communication. The present interpreter

board could be removed, and the motor drivers could be controlled by any I2C

master. This could be the PICNIC, allowing the motor drivers to be controlled by

a remote computer or other TCP/IP device. This is not within the scope of this

thesis.

25

2.2 Data Acquisition and Communication Systems

Figure 2.4: Data Acquisition and Communication System

The data acquisition and communications systems, Figure 2.4, were designed to

gather data from the LOMAC. The data acquired from sensors on the LOMAC

will be used to reconstruct the LOMAC’s motions. The system employs several

sensors: accelerometers on 3 axes, inclinometers on 2 axes, a digital compass, and

a GPS. In addition to these sensor readings, motor voltages and voltages from

motor current-sensing amplifiers are sampled. The communication is facilitated

by the use of the stand alone TCP/IP stack and Ethernet controller in the Wiznet

IIM7010A system. All of these systems are centrally controlled by the PICNIC

system which functions as the Central Processing Unit facilitating the movement

of the information.

26

These systems are spanned across multiple boards, Figure 2.5, to create the sensor

package. All of the boards are connected via a 40 pin IDE cable that pass power

and access to the pins of the PICNIC to the other board and provides for future

expandability. The bread board is the only non printed circuit board but is a

prototyping board used for integration of systems with out circuit boards. This

includes the Inclinometer PIC and the LCD screen.

Figure 2.5: Sensor System Board Diagram

27

2.2.1 GPS Reader

Figure 2.6: GPS Reader System Diagram This system, Figure 2.6, uses a PIC 18F452 to read one sentence from a GPS

(Rockwell, 1998), making that sentence available on-demand to another PIC via

the I2C bus. This is done because the GPS independently outputs several different

sentences every second. These sentences are each approximately 80 bytes long.

The GPS outputs them as asynchronous serial data at 4800 bps. The PIC reads the

appropriate sentence coming from the GPS and then internally moves it to a data

section available to another device via I2C.

The GPS reader is an I2C slave device. An I2C request is capable of generating an

interrupt on the system. When the GPS reader receives a read request, it transmits

28

the last complete RMC sentence. The GPS reader only stores the Recommended

Minimum Specific GPS/TRANSIT Data (RMC) sentence,

Figure 2.7 ($GPRMC tagged sentence (NMEA, 2004)).

•

$GPRM RMC = 1 = U2 = D3 = La4 = N5 = Lo6 = E 7 = Sp8 = Tr9 = U10 = M11 = E12 = C

Appendix

appropriate

transmissio

received fr

transmittin

the I2C mo

data in the

read upon

RMC

C,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,ddmmyy,x.x,a*hh

Recommended Minimum Specific GPS/TRANSIT Data

TC of position fix ata status (V=navigation receiver warning) titude of fix

or S ngitude of fix or W eed over ground in knots ack made good in degrees True

T date agnetic variation degrees (Easterly var. subtracts from true course) or W hecksum

Figure 2.7: RMC NMEA Tag Definition (NMEA, 2004)

C contains the code that reads the serial GPS sentences, moves the

sentence to the outgoing string buffer, and handles the I2C slave

n. The string is long enough that it is likely that a serial byte or bytes

om the GPS will be in the incoming buffer while the I2C slave is

g the outgoing string. To avoid data loss, after each byte is loaded into

dule for transmission, the program checks the serial buffer. If there is

buffer, it is moved to a second buffer from which serial data can be

completion of the I2C transmission. After a sentence is completely

29

received, it is copied to the outgoing string buffer, and the program begins

looking for the next GPS sentence. This setup makes the GPS data available to the

system on demand and speeds up the transfer from 4.8 kbps to between 100 and

1,000 kbps.

2.2.2 Inclinometer System

Figure 2.8: Inclinometer System Diagram This system, Figure 2.8, is similar to the GPS system in that they both use a PIC

18F452 and are I2C slaves. The inclinometer, T2 3600 (US Digital, 2004), by US

Digital is an optical encoder that has a weight on it and is magnetically dampened

to minimize oscillation. Upon a change in inclination, the optical encoder outputs

30

signals on two channels together to generate a quadrature signal. This quadrature

signal consists of two square waves that are 90º out of phase with respect to each

other. The direction of the phase shift is related to the direction of rotation, i.e., if

channel A is +90º out of phase with channel B, then the rotation is clockwise.

This signal can be seen in Figure 2.9. Each channel’s signal is generated from the

output of a photo sensor, stimulated from an LED. Between the photo sensor and

LED is a transparent, rotating disk with evenly spaced markings that block light

from the LED. Each period represents the passage of one mark on the encoder

disk.

2 Increments Clockwise 2 Increments Counterclockwise

Figure 2.9: Quadrature Signal This quadrature signal is decoded by the PIC. This is accomplished by connecting

channel A to port B bit 4 on the PIC and channel B to port B bit 5. Bits 4 and 5

can be set to generate an interrupt on change. On this interrupt, the PIC checks the

state of both pins. The current state of the pins and the previous state of the pins

are used with a table to determine whether to add or subtract from the inclination

Channel A Channel A

Channel BChannel B

31

value, as seen in the source code in Appendix D. The counter is stored in a signed

integer (2 bytes). This value can be accessed by another device via I2C. Unlike the

GPS system, which recognized a data request by the generation of an interrupt,

the I2C slave code uses polling. The program checks to see if an I2C address

match has occurred, and when a match occurs, the inclinometer transmits its

inclination counter value.

The system has no built-in reference, therefore, the system is referenced to the

initial inclination from when the program starts. The counter is zeroed every time

the program starts, and the counter is modified by the signal from the

inclinometer. The encoder disk in the inclinometer has 900 marks on it. Moving

between marks moves the system through 4 binary states: 11, 10, 00, 01. The next

state starts the process over again at 11. This will generate 4 interrupts and 4

increments of the counter per cycle, giving the system a resolution of 0.1º.

The inclinometer system allows for the quadrature decoding based on interrupts.

Unfortunately, at this time only one inclinometer was available. Another

inclinometer should be implemented using the same system with a different I2C

slave address. This would allow measurement of the inclination along a second

axis.

32

2.2.3 Digital Compass

Figure 2.10: Digital Compass System Diagram The digital compass system, Figure 2.10, is based on Honeywell’s HMC 1052

(Honeywell, 2003). The digital compass outputs its heading via two analog values

that represent the X and Y components of the vector to magnetic North. With the

use of geometry, these values can be used to find the heading, as shown in Figure

2.11. Unfortunately, PIC C18 does not support trigonometric functions at this

time (but will in the future), therefore, the magnitudes of the North/South

component and East/West component are transmitted instead. The heading can

therefore be resolved by post-processing. The analog signals produced by the

33

digital compass are sampled by the PICNIC board. The digital compass board is

connected to the system’s accelerometer board, described next.

Figure 2.11: Heading Geometry

2.2.4 Accelerometers Two accelerometers were evaluated for use in this system, ADXL202E (Analog

Devices, 2000) and ADXL311 (Analog Devices, 2003), both made by Analog

Devices. The main difference between the ADXL202E and ADXL311 is the

available output generated by each. They are both ± 2G accelerometers and

operate at voltages from 3V to 5.25V. The ADXL311 outputs the acceleration as

an analog voltage. The ADXL202E outputs the acceleration as an analog voltage,

like the ADXL311, but also produces a digital output. When the voltage is being

used to measure the acceleration at 5V, 0 G is at 2.5V and 1 G is 0.312V offset

from that. In digital output the acceleration is found from a PWM signal. A 50%

34

duty cycle would represent 0 G. A 12.5% (1/8) change in the duty cycle

corresponds to a 1 G acceleration.

One thing to consider about these two outputs is the amount of time required to

acquire each. Using the digital output, the amount of time it takes is based on the

period of the PWM wave. The time for the acquisition by this method can take

just over one period and up to two periods. If the command to acquire the

acceleration is called just after a high pulse starts, then the processor must wait for

the next high pulse to start, resulting in a total sampling time of nearly 2 periods.

This means that at the shortest setting for the period, the acquisition can take as

much as 1 ms or as little as just over 0.5 ms. The shorter the period, the lower the

measurement resolution and the more significant the effect of the error induced

from polling. This does not seem like much, but the project design includes three

accelerometers and other devices as well, so the latency accumulates. To obtain

the optimal resolution, the accelerometer must be set to use a frequency of 350 Hz

for the PWM signal, yielding a possible maximum acquisition time of 5.7 ms.

The time it takes to acquire the acceleration using the analog method is

significantly different. The PIC’s minimum analog to digital conversion clock at

40 MHz is 1/64 the oscillator, which translates into 1.6µs per TAD (a TAD is the

time it takes for one bit to be converted). It takes 11 TADs to convert a 10-bit

35

value, or 17.6µs. As stated previously, the design needs to read 3 accelerometers.

This means that the A/D (Analog to Digital) module will need to switch between

analog channels. When switching channels, there is a required amount of time the

A/D module needs to be on that channel before a conversion can start. This time

varies with temperature, but following an example from the datasheet, for 50°C, a

12.86 µs delay is needed. With the required time for channel changing, the total

conversion time is 30.5µs.

Table 2.1: Conversion Times

0.000 000 025 s 0.025 µs Oscillator 0.000 001 600 s 1.60 µs TAD time

0.000 017 600 s 17.6 µs 10-bit A/D conversion time

0.000 036 800 s 30.5 µs

10-bit A/D conversion with delay for channel changing

0.001 000 000 s 1000 µs Max time for shortest period digital acquisition

0.005 700 000 s 5700 µs Max time for optimal resolution digital acquisition

Comparing the acquisition time between digital and analog, it can be seen that the

shortest digital acquisition time is more than 30 times longer than the analog

acquisition time than. In the amount of time required for one digital reading with

the optimal period, over 180 analog readings could have been made. In the initial

design stages there was a target of 100 samples per second. This criteria lead to

the selection of analog acquisition.

36

To use the analog outputs of the accelerometer, the voltage output is amplified to

provide better resolution. To amplify the signal, an instrumentation amplifier

design from the data sheet for Microchip’s op amp, MCP604 (Figure 2.12).

Figure 2.12: Microchip Instrumentation Amplifier (Microchip, 2004)

On the accelerometer board, each acceleration channel uses an instrumentation

amplifier. The V2 of each amplifier block was connected to an adjustable

precision 2.5V voltage shunt. The VREF of all the amplifiers were connected to the

same precision 2.5V voltage reference. This was done so that the amplification

would occur around the 0 G value of half the input voltage, equal to

approximately 2.5 volts. The adjustable voltage shunt allows for correction of an

37

offset that the sensor may have. In the circuit R2, R3, and R4 are 10kΩ ±1%

resistors, resulting in the equation 2.1.

VOUT = (V1 – 2.5V)(1 + (2* 10kΩ)/ RG)(10kΩ/10kΩ) + 2.5V E.Q. 2.1

The goal of the amplifier was to make 1 volt equal 1 G; this required a gain of 3.2.

An RG of 9.06 kΩ is needed to achieve this gain; an 8.55kΩ ±1% resistor in series

with a 1kΩ potentiometer was used to achieve this value.

Onboard, each accelerometer channel has two adjustments. Each channel has an

adjustment to regulate the center and the gain of the channel. This allows

calibration of the accelerometer system. The four channels of the acceleration are

Y, Z, X and Z again. The Z axis is measured twice because two vertically

mounted 2-axis accelerometers are used with duplication of one axis. Low pass

filters were added after the board construction to reduce high frequency noise.

These filters are not set to an optimal cutoff frequency, but they still greatly

reduce the noise in the accelerometers.

The accelerometers are read by the PICNIC directly using the analog inputs. The

PIC used by PICNIC has a 10-bit A/D converter. This gives 1024 steps of

resolution. In this application, the references are ground and the PIC supply

voltage, which is approximately 5 volts. An A/D conversion result of 0 would be

38

0 volts and 1023 would correspond to the input value. This can be problematic

since there is noise in the supply voltage. The accelerometers need to be

calibrated, but additionally the voltage of the system should be checked. It should

be close to 5 volts.

2.2.5 IIM7010A The Wiznet iinChip (Wiznet, 2002) allows easy use of TCP/IP communication by

handling the added overhead of this protocol. The iinChip handles pings, ARPs,

and packet formatting. The iinChip module being used is the Wiznet iinChip

IIM7010A. The IIM7010A integrates the iinChip W3100A (Appendix 2) and an

Ethernet controller. The IIM7010 is accessed from a Microchip PIC

microcontroller via the I2C bus. The iinChip is instructed by the microcontroller

to establish a connection or to wait for a connection on a certain port. The status

of the connection is then polled. After a connection is established, data is sent and

received freely. The iinChip buffers all communication data in two 8k byte buffer

for one transmission and another for reception. Incoming data is automatically

buffered and outgoing data is placed in the buffer prior to being sent. The device

uses a 4-byte pointer, though it uses only 2-bytes of this for addressing. The extra

bits in the pointer are used by the device to store information about the packet in

which the data was received or sent. Communication consists of checking the

39

status of the device, placing or reading information to or from the buffers, and

telling the device that reading or writing is complete in order to free allocated

buffer space.

The device has four channels, with a status register for each channel. For this

application, only one channel is used. The extra channels allow additional

simultaneous connections to the device. The status register shows whether

information has been received and the status of the connection (open, closed or

listening). There is also a register for device commands and additional status

information, such as the following: initialize the device, initialize the channel,

send data in buffer, and finished reading data in buffer.

The device is initialized by providing it with the network parameters. This

includes the IP address, gateway address, subnet mask, and the MAC address for

the device. When initializing a channel, the communication parameters are

specified. This includes the type of communication (TCP or UDP), the port on

which to communicate, and whether to wait for a connection or to initiate one.

This method of communication makes it viable for a PIC microcontroller to

communicate over a TCP/IP network.

40

2.2.6 PICNIC The PICNIC is the communications system that gets the data from all the sensor

systems. The PICNIC gathers the sensor data by use of the analog channels or the

I2C bus. The PICNIC also controls the IIM7010A via the I2C bus, controlling the

TCP/IP functions. In this case the PICNIC is the I2C master.

When the PICNIC is started, it first initializes the IIM7010A and then prepares a

socket. The IIM7010A is initialized with the parameters in Table 2.2. Next, socket

0 is prepared to listen on port 23, which is the standard port for Telnet, using TCP

communications. The IIM7010A waits for another device to connect to it on port

23 and then negotiates a connection.

Table 2.2: IIM7010A Settings

Gateway Address 192.168.1.1

Subnet Mask 255.255.255.0

MAC Address 00-A0-24-BB-D8-6A

IP Address 192.168.1.50

Initial Retry Time 100ms

Retry Count 255

RX Memory Allocation 8 kb to Ch 0

TX Memory Allocation 8 kb to Ch 0

41

While waiting for a connection, the PICNIC reads the analog inputs and the

inclinometer. It then displays the values on an LCD screen. The main purpose of

this is for calibration of the accelerometers, but this function is also useful for

providing debugging information.

When the PICNIC reads an accelerometer, it reads it 16 times and averages the

results. The averaging helps reduce noise by combining multiple data points,

reducing error generated by noise. It then converts the value to acceleration by

subtracting the equivalent of 2.5 volts from the averaged sensor reading,

multiplying it by 1000, and dividing it by the equivalent of 1 volt. This gives a

value that has 3 decimal places using fixed point notation. This value is then

converted into an ASCII string for either transmission or display.

When the PICNIC reads the digital compass, it reads it 16 times and averages the

readings like those from the accelerometers. The averaging is used to reduce error

from noise. The values are also centered based on an internal calibration value.

These values are then converted to ASCII and are combined into a null terminated

string with the values separated by a space. These values will be post-processed to

determine the heading.

42

Along with the digital compass reading, an optional analog channel is read. This

channel can read any voltage value that is within the range of the A/D converter:

0 to 5 volts relative to the ground of the system. This reading is also converted to

an ASCII value and appended to the null terminated string that contains the digital

compass readings. This was included for future expansion, as well as to input the

voltage across a current-sensing resistor. The string created from the digital

compass and the optional analog channel can be either displayed on the LCD

screen or transmitted back to the client.

After the PICNIC has finished displaying the analog channels and the

inclinometer on the LCD, it delays for 0.2 seconds, so the data can be seen by the

operator. It then sends the command to clear the screen and waits for 0.06 seconds

for the screen to finish clearing. The PICNIC then checks the status of socket 0 on

the IIM7010a. If the status reflects that a connection has been established, then

the program enters the data transmission routine. Otherwise, it repeats the cycle,

going back to check the analog channels and inclinometer and refreshing the LCD

screen.

If the connection has been established, the PICNIC moves into data transmission

mode. The data that is transmitted is based on the number of loops of the data

transmission code. The first time it loops through, it transmits the GPS

43

information. Every time the GPS information is transmitted, the loop counter is

reset. The GPS information is retransmitted after 250 loops of the code. The

accelerations, digital compass data, the optional analog channel, and the

inclinometer are output every five loops. Each GPS sentence is transmitted

approximately once per second. This means the acquisition rate for the rest of the

data is approximately 50 times per second.

At the end of each loop the program checks to see if the connection is still active.

If the connection has been lost, the program breaks from the loop and reinitializes

the socket. The program functions in several states: device initialization, socket

initialization, waiting for connection, and connected.

The PICNIC is capable of receiving data from the client, but it has been disabled

since it is unnecessary in this application. Functions supporting reception of data

are included in the code, since these were used in the initial development of the

communications program. Future applications may use this function.

The amount of data that can be transmitted is dependent upon the data rate and the

network reliability. If data is being generated faster than the data can be

successfully transmitted, then data loss can result. Successful transmission

requires the transmitted data to be acknowledged by the receiver. If the data that

44

is being transmitted is not acknowledged, the newly acquired data can overrun the

unacknowledged data. This will result in a loss of the older data.

45

3.0 Testing and Results During the course of this project several tests have been conducted. Some tests

were conducted in conjunction with the LOMAC and others were conducted

independently. The independent tests were conducted in a car. In the car, there

were two tests: a low speed test, at speeds similar to what the LOMAC should

achieve, and a high speed test, used to evaluate the system with readings of higher

magnitude.

3.1 Fall 2003 Pool Test In the fall of 2003, the LOMAC was tested in the South Gate pool on the campus

of Florida Institute of Technology. The purpose of this test was to test the motor

drivers, the R/C interpreter, and the integrity of the LOMAC hull.

When running the LOMAC in the pool, it was observed that the boat did not reach

the desired speed. The maximum speed the LOMAC could achieve was well

below the design speed. During the test, the operator tried to control the boat

using the differential steering but could not generate an effective turning moment.

The boat would turn slightly but not enough to effectively control the boat. While

running the boat at full speed, one of the MOSFETs on a motor driver board

failed and would need to be replaced at a later date.

46

It was also observed that leaks in the power transmission caused the boat to take

on a significant amount of water in the jet compartment. Over time, some of this

water seeped through the bulkhead into the engine compartment but not until

there were a couple of inches of water in the jet compartment.

3.2 Spring 2004 Pool Test This test was conducted after Eduardo Gonzales had reconditioned the hull,

constructed new water resistant housings for the motor control circuitry, and

resealed the bulkheads. One of the purposes of this test was to record data using

the PICNIC and sensor suite. Another purpose was to familiarize Eduardo with

the current performance characteristic of the LOMAC. At the time of this test, the

accelerometers’ outputs were not filtered.

At first, the LOMAC did not perform as well as it had in the previous tests. In the

initial test, the LOMAC could not move at all. After the initial trial the impeller

compartment was opened and it was found that the impellers were not turning

with the shafts. This was corrected and a second trial was attempted. In the second

trial, LOMAC performed as it had in the fall trial. The LOMAC still could not

47

achieve a speed that would be adequate for the scale model, but no additional

component failures occurred during these trials.

The digital compass and the inclinometer were not functioning during the test. It

was also seen that even though the GPS acquired a signal, there was no change in

the position during the test. The only data obtained was the acceleration data seen

in Figure 3.1 (landscape version in Appendix L).

Figure 3.1: Boat Test - Acceleration Data

48

There is a large amount of noise in the data. There appears to be an approximate

0.3 G noise band. The gap in the plot is a section where there was a buffer

overrun in the communications. There was only a small amount lost, but to ensure

signal integrity, the data was truncated to known good points based on GPS

sentences.

3.3 Car Test 1

Figure 3.2: Car Test Vehicle This test’s purpose was to simulate the model-scale speeds the LOMAC was

designed to achieve. In this test the PICNIC and sensor suite were secured into the

rear passenger seat in a Honda CRV, Figure 3.2. The GPS antenna was removed

from the sensor box so that it could be placed on the dashboard in order to receive

49

a signal. Since the last test, the accelerometers had been fitted with low-pass

filters to reduce noise. The digital compass and the inclinometer were both

reworked since the last test.

In the post-processing, it was found that the digital compass still did not function

correctly. It was also found that the GPS did not start correctly. It is a known

problem that the GPS occasionally does not initialize properly when the unit is

turned on. At present, the only way to correct this is to reset the main power.

Figure 3.3: Florida Tech Campus (Florida Institute of Technology, 2004) The test course was a single lap around the residents’ parking lot across from

Roberts Hall, on the campus of Florida Institute of Technology in Melbourne,

Florida (Figure 3.3, Appendix K). There were no noticeable inclines on the test

50

course. Despite the aforementioned problems, the system recorded the

accelerations and the inclinometer. Figure 3.4 (landscape version in Appendix M)

shows the four accelerometer outputs. Inspection of the inclination data revealed a

trend which is best understood when overlaid with the acceleration data, as seen

in Figure 3.5 (landscape version in Appendix N).

Figure 3.4: Car Test 1 – Acceleration

51

Figure 3.5: Car Test 1 - Acceleration and Inclinometer

As in the previous test, there is a small gap in the data do to a communications

buffer overrun. The data was again truncated to include only data known to be

good based on GPS sentences. Also, like the previous test, there was some noise

in the acceleration measurements, but it was greatly reduced to approximately a

0.04 G noise band.

3.4 Car Test 2 In the next car test, the devices that were not working were fixed. Like the first

car test, this one took place in the resident’s parking lot and was conducted at

52

speeds similar to those the LOMAC should achieve. This test consisted of two

laps of the parking lot. Figure 3.6 shows the logged GPS locations. During this

test, all of the sensors functioned.

Figure 3.6: Car Test 2 - GPS Path.

The accelerations and the inclination recorded during this test are shown in Figure

3.7 (landscape version in Appendix O).

53

Figure 3.7:Car Test 2 - Accelerations and Inclination The heading was recorded by both the GPS and the digital compass. The GPS

only records the heading when there is a change in position and the recorded

heading is based on that change. If there is no motion, the GPS heading is

recorded as 0 degrees. The offset values for the digital compass were calculated

based on ranges of values recorded. The compass provides a North/South

component and an East/West Component. The center value, or offset, of each of

these components is subtracted from the recorded value, and the resulting quantity

is scaled such that both components have the same range. Then, the ATAN2

function is used to find the heading. The heading according to the GPS and the

digital compass for Car Test 2 are shown in Figure 3.8.

54

Figure 3.8: Car Test 2 - Heading

The speed according to the GPS was also recorded and is shown in Figure 3.9.

55

Figure 3.9: Car Test 2 - GPS Speed

3.5 Car Test 3 Car Test 3 was conducted under normal city driving conditions to see how the

system responded under higher speeds. The test was conducted between the

parking lot on Country Club Road and the Sugar Mill Apartment complex, in

Melbourne, Florida. This path can be seen in the GPS track in Figure 3.10.

56

Figure 3.10: Car Test 3 - GPS Path

The acceleration and the inclination during this test are shown in Figure 3.11

(landscape version in Appendix P). During the test, three speed bumps were

encountered between times 175 second to 210 seconds.

57

Figure 3.11: Car Test 3 - Acceleration and Inclination As in the previous test, the speed was recorded by the GPS. It can be seen in

Figure 3.12 that the maximum speed in this test was 26 knots almost twice that

from the previous test.

58

Figure 3.12: Car Test 3 - Speed

The heading according to the digital compass was processed in the same manner

as the previous test, which revealed a problem with that method. It requires the

sensor package to travel a full 360° degrees in the course of the test to be properly

calibrated using the present method. During the course of this test, the sensor

package did not travel a full 360°. The problem is obvious in Figure 3.13, which

shows the heading according to the GPS and the digital compass.

59

Figure 3.13: Car Test 3 - Heading

3.6 Engine Power Test Determining the power used by the engines was an important element in the

development. After the first failure of the MOSFETs in the pool tests, there was a

desire to know the current drawn by the motors. The current supplied to the motor

was found by using current sense resistors and a current sense amplifier. Two

0.005Ω resistors in parallel, yielding a 0.0025Ω resistance, were placed in series

with the motor on the higher voltage side of the motor. The voltage was measured

across the resistance using a current sense amplifier with a gain of 100. The

60

current sense amplifier outputs 100 times the voltage sensed across the resistors.

Knowing the voltage across a known resistance provides a measure of the current,

by use of equation 3.1.

I = V/R EQ 3.1

In the lab, the current was measured under two conditions. In the first condition,

the motor was not connected to anything, so it was essentially unloaded with only

internal frictional resistance. Figure 3.14 shows the current during the unloaded

test.

Figure 3.14: Motor Current - unloaded

61

In the second condition, the engine was attached to the jet drive system. Figure

3.15 shows the current running through the motor while attached to the jet drive

train, but running in air.

Figure 3.15: Motor Current with Drive Train

62

4.0 Discussion There were a number of tests and types of tests used in the evaluation of the

system. These tests provided a great amount of information about the design and

resulted in several modifications of the systems.

The fall and spring pool tests showed that the boat was greatly under-powered.

They also showed that with the present powering, the differential steering would

not work. This is because the jet drive propulsion system was not providing

enough thrust and could not generate enough moment to turn the ship in the

desired space. If the propulsion system provided greater thrust, it is possible that

the boat could be controlled using differential steering. Since the propulsion

system needs to be altered, however, the timing and synchronization systems were

tabled until a viable propulsion system could be installed. The motor driver

boards are equipped to receive data from a Hall Effect sensor to determine the rate

of revolution of the motor shaft when a new propulsion system is installed.

The failure of a MOSFET during the fall 2003 pool test was determined to be a

result of overheating. This problem was addressed by adding a small brushless

DC fan into the new water resistant boxes that house the motor driver and battery.

This fan blows directly over the heat sink attached to the MOSFET (Figure 4.1),

63

removing excess heat. During the spring 2004 pool test, the new water resistant

housings with the fans were used. During this test, there was no damage to the

MOSFETs; the fans provided the needed cooling.

MOSFET

Fan

Figure 4.1: Motor Driver and Fan

During the spring 2004 pool test, the PICNIC communication system was used.

There were several problems found in this test. Looking at the data collected, the

GPS worked but did not pick up any change in position. This is likely due to the

small distance covered. This is the most likely reason as the GPS time kept

changing, but none of the base data changed. If the GPS device had stopped

transmitting, then the result would have been the same GPS data repeated with no

time change.

After examining the acceleration data captured from the spring 2004 pool test, it

was seen that the analog inputs needed to be filtered. There was a large noise

band, making it difficult to distinguish the small changes in the acceleration that

64

are needed to determine motion. After the testing, a low pass filter was added to

each of the accelerometer channels to reduce the noise and to try to prevent

aliasing. The cut off frequency of the added filter is too high, but it is the best that

could be added at the time without major modification of the circuit board.

Comparing the results from the first car test to results from earlier pool tests, the

filter greatly reduced the noise but did not eliminate it.

During the first car test neither the GPS nor the digital compass were operating

properly. The GPS had not initialized correctly. In the investigation of the failure

of the digital compass, it was found that one of the analog channels from the

digital compass was not connected to the analog channel of the PIC. This was

corrected, but the range of output was less than optimal. To fix this, the gain of

each of the amplifiers on the board was increased. At first, the range was

increased, but over time the range decreased again. The original design for the

integration of the digital compass left the magnetic set and reset straps on the

compass unused, since the author was led to believe they were unnecessary for a

low accuracy compass. The following approach was taken since there was a

mistake in the digital compass circuit design. Based on a recommendation from a

Honeywell Application Note, the circuit used a DC-DC converter to step up the

voltage applied to the set/reset strap on the compass. The inductive DC-DC

converter both induced excessive noise in the circuit and reduced the battery life.

65

This high voltage was used in the compass set/reset circuitry to generate a high

current to realign the magnetic field around the magneto-resistive sensor. The

current required to realign the magnetic field in a compass application is

significantly less than that which was being applied. The current needed to realign

the magnetic field could be achieved using the existing 5-volt supply. Through

experimentation, it was found that triggering the set and reset pins on the digital

compass board reset the range. Unfortunately the only way to presently trigger the

pins without redesigning the compass board is to temporarily connect these pins

to the 5-volt supply. The increased range increases the resolution of the compass.

With the reduced range, it still produces a 360° response when moved in a

complete circle, but the accuracy of the reading is greatly reduced.

From the acceleration and inclination data collected during all of the car tests, it

can be seen that the inclination follows the x-axis acceleration even though there

was minimal change in angle. This is due to the way in which the inclination is

measured. It is measured using a hanging weight which aligns with the total

acceleration vector acting on it, which is gravity in the static case. Additional

accelerations resulting from the motion of the system contribute to the total

acceleration vector, and also act upon the weight in the inclinometer. This can be

factored out, but will be difficult since it would require the inclination to be

66

corrected based on the measured acceleration. The corrected inclination would

then be used to properly orient the measured components of acceleration.

From the data collected in the pool tests and the car tests, it can be seen that there

are gaps in the measurement time series. These gaps result from buffer overflows.

In the case of a buffer overflow, the data loses its uniformity. In processing, when

a buffer overflow occurred, the associated data collected was discarded. What

remained were points that were justifiably good based on the GPS sentences, and

the time loss was estimated from the GPS time. This is less than ideal. Buffer

overflows occur when a lot of the transmitted information is not acknowledged.

When transmitted data is acknowledged the buffer space it occupies is released. If

the data being put into the buffer exceeds the free space, it overwrites the oldest

information in the buffer. Data is not acknowledged for many possible reasons,

including network collisions and wireless signal interference.

After examining the raw data from the car tests, it was seen that the timing

scheme used in the data collection was flawed. The scheme used during those

tests was based on the code execution time, which was assumed to be evenly

spaced. The GPS sentence was read approximately every second. This was not the

case. The GPS sentences were repeated in some cases and sentences were missed

in others. It was seen that the spacing of the GPS data was not consistently one

67

second. Because of the sensitivity to time in determining position from

accelerations, the resulting error would be excessive. The timing scheme was

changed, tying the timing to the processor clock. In this configuration, an

interrupt is generated every millisecond, adding one to a counter. This internal

time base is output with the sensor data each time, giving each sensor reading a

time stamp. Initially the system was set to read the sensors 40 times a second and

the GPS once per second based on the timer count. According to the time stamp,

in the original configuration, the first of the sensor readings was lost. It was then

decided to reduce the sensor reading to 25 times per second. At this rate the first

sensor reading was not lost. Also, at this rate, the chance of a buffer overflow is

reduced, since there is only about half the data being transmitted in the same

amount of time.

In car tests 2 and 3 the heading measured by the digital compass and GPS was

captured. From the headings in Figure 3.8 from car test 2, it can bee seen that the

digital compass and the GPS agree well. In this case, the digital compass is likely

more accurate because of the way in which the GPS heading is found. The

heading from the GPS is determined based on the movement. The resolution of

the motion is limited by the ability of the GPS device to sense a change in

position. Looking at the heading in Figure 3.13 from car test 3, it can be seen

there is a disparity in the heading from the digital compass and the GPS. In this

68

case, the GPS is more accurate. The disparity occurs because of the calibration

method used for the digital compass. For the calibration method to work, the

sensor package must be rotated 360°, producing readings over the whole

measurement span. From car test 3’s GPS path, Figure 3.10, it can be seen that the

car never faced in the west direction. This resulted in a faulty calibration of the

digital compass, offsetting the headings. This could be corrected based on the

GPS results, but it would be better in the future to make sure a good calibration

turn occurs during the test, such that the sensor orientation spans from 0° to 360°.

Proper use of the set and reset functions of the digital compass should allow the

digital compass to be calibrated once instead of with every use.

Looking at the car test accelerations, it can be seen that with use of moving

averages, a good measure of the acceleration is achieved. The moving average

partially compensates for the remaining noise in the system. The x and y

components of acceleration recorded when the system was still (speed = 0 by

GPS) were flat lines. In these cases, the acceleration does not read zero, because

the accelerometers were not tuned on that day. This error is static and can be

factored out. In the z axis accelerations, the noise-like patterns are likely due to

vibrations in the car. From the record of z-axis accelerations from car test 3, it is

obvious where the car went over the three speed bumps in the parking lot; these

are the short large spikes.

69

The test of the engines on the LOMAC had two purposes; first to develop the

current sensor and second to see the new drain of the motors in the air. The sensor

that was developed will be used again later to measure the current drawn by the

motors in water trials. Looking at the results in Figure 3.14 and Figure 3.15, the

maximum current for the motor with no external resistance was about 2.25 amps

and with the resistance of jet drive was about 2.9 amps. These values agree with

idle current drain specified for the motor.

70

5.0 Conclusions and Recommendations The systems designed here represent new configurations of recent technologies.

The PICNIC system can be used in a wide range of other applications for remote

data acquisition over a network. Each of the sensor systems could be applied to

different applications. The current measuring system and the motor control were

designed to be used at a later time in the LOMAC project.

The system designed here is a network of other systems working in conjunction

with each other. The GPS reader system provides positioning data, speed data,

and heading data (while moving) on demand over the I2C bus. The inclinometer

system provides the current inclination in an axis on demand over the I2C bus.

The accelerometers provide 3 axes of acceleration in an analog format. The digital

compass provides the heading to magnetic north in an analog format. The current

sense resistor can measure high currents and output an analog equivalent to it. The

PICNIC gathers all of the data provided by these sensors and converts it into an

ASCII formagt and then sends it to the IIM7010A. The IIM7010A then uses

TCP/IP communication and Ethernet to transmit them to a Telnet client. The

Ethernet is converter to Wireless Ethernet for wireless communications.

71

The most unique system, and also the most refined system designed here, is the

PICNIC communications system. The system works well in this application, but it

also has the potential for so many other applications. In this application, only one-

way communication occurs, but the system is also capable of two-way

communications. The system works well in the one-way streaming of

information. There is the occasional buffer overflow, but the chance of an

overflow is decreased by reducing the amount of data transmitted per second.

The analog systems, including the accelerometers, digital compass, and current

sensor, worked well in the present system. The systems work adequately as

currently configured, but could be redesigned based on some of the lessons

learned. The analog channels should use an anti-aliasing low pass filter suitable

for the data acquisition rate. This would remove high frequency noise and prevent

aliasing. The analog channels could also use impedance matching circuitry to

minimize capacitive coupling while maintaining better signal integrity. Another

modification that could be made is for the set and reset connections of the digital

compass to be connected to the PIC and utilized. These modifications could be

done by redesigning the accelerometer board.

The use of the inclinometer can provide the inclination in an acceleration-free

environment. In this system, the inclinometer is based on gravitational

72

acceleration. The gravitational acceleration vector is tracked by a mass. The

acceleration the system experiences also acts on this mass. This makes the

analysis based on this inclination reading difficult to decipher. Using an external

reference not based on gravitational acceleration would provide a simpler motion

analysis. An external reference to consider is the orientation of the magnetic north

vector. By adding a third axis to the digital compass, the orientation of the system

can be found relative to magnetic north instead of gravity. Another option would

be to use a gyroscope. The motions relative to the gyroscope would provide a

good reference. If the GPS and power board were to be redesigned, one important

change should be made. On the new board, the GPS reset should be connected to

the GPS reader PIC. This would allow the PIC to reset the GPS if it did not

initialize properly.

The motor control system is a good system, but the jet drive system does not work

as anticipated. The motor control can be applied to a new drive system. Besides

the motor control systems, the current measuring device can also be used in part

to determine the power consumption of the motors with the new drive system. For

simplicity, the jet drive system could be replaced with a simple propeller system.

When the new drive system is installed the revolution circuitry can be utilized to

synchronize the engines.

73

Pic Basic Pro and C18 programming languages where both used during the course

of this project. Pic Basic Pro was a good starter language because simple

operation, many software based commands and it ability to work with several

series if PIC microcontrollers. C18 was a more complex programming language.

This complexity also made it much more powerful and versatile than the Pic

Basic Pro.

This project has examined many different technologies and combined some of

them in a new way to create a wireless data acquisition system for measuring the

dynamic conditions useful in determining hull performance. The results show that

most of the chosen data acquisition technologies work well, and the results also

identify weaknesses in analog signal conditioning and inclinometer used in the

system. The information gained will be applied in future tests and improvements

of the LOMAC as well as other projects requiring similar sensor and data

acquisition capabilities.

74

References

Adcock, E.; Bartlett, J.; Culliton, W.; Jordan, T.; Mau, J.; Bare, E.A.; Florance, J.; Kahng, S. (2001). “An embedded wireless data acquisition system for wind tunnel model applications”. ICIASF Record, International Congress on Instrumentation in Aerospace Simulation Facilities (pp. 327-336). Institute of Electrical and Electronics Engineers Inc.

Analog Devices. (2003). “Low-Cost, Ultracompact ±2 g Dual-Axis

Accelerometer”. ADXL311. Analog Devices. (2000). “Low-Cost ±2 g Dual-Axis Accelerometer with Duty

Cycle Output”. ADXL202E*. Bentham, Jeremy. (2002). TCP/IP LEAN: Web Servers for Embedded Systems

(2nd ed.). CMPBooks: Lawrence, KS “Bluetooth FAQ & Knowledge Base: What are some of the technical details of

the Bluetooth wireless specification?” Bluetooth.org- - The Official Bluetooth Membership Site June 2004. <https://www.bluetooth.org/admin/bluetooth2/faq/view_record.php?id=44>.

Burland, Travis & Mark Cencer & Patrick Hatton. (2003). “LOMAC Littoral-

Operation Multipurpose Auxiliary Craft”. Marine Field Projects Report, Florida Institute of Technology

Edwards, Dana B. (1998). “Mobile data acquisition using GPS and wireless

technologies”. Instrumentation in the Aerospace Industry : Proceedings of the International Symposium (pp. 425-433). ISA, Research Triangle Park, NC, USA

Florida Institute of Technology, University Publications. (2004) “Florida Tech

Campus Map”. Honeywell Sensor Products. (2003). “HMC1051/HMC1052/HMC1053”.

75

Lohachit, W.; Bachnak, R.; Michaud, P.; Duff, S.; Adams, J.; Steidley, C. (2003). “Wireless Data Acquisition and Logging in Shallow Water Environments”. IEEE International Symposium on Intelligent Control – Proceedings (pp. 980-984). Institute of Electrical and Electronics Engineers Inc.

Microchip Technology, Inc.(2004). “MCP601/602/603/604: 2.7V to 5.5V Single-

Supply CMOS Op Amps”. DS21314F. Mitchell, Kyle; Rao, Vittal S.; Pottinger, Hardy J. (2002). “Lessons learned about

wireless technologies for data acquisition”. Proceedings of SPIE - The International Society for Optical Engineering (pp. 331-341). The International Society for Optical Engineering

“NMEA 0183” DIE GPS-HOMEPAGE VON KLAUS H. HIRSCHELMANN .

August 2002. June 2004. <http://www.kh-gps.de/nmea-faq.htm>. Raygan, Robert E. (2002). “Wireless remote sensor data acquisition and

management using linux OS, MURS and 802.11b”. IEEE Vehicular Technology Conference (pp. 219-223). Institute of Electrical and Electronics Engineers Inc.

Rockwell Semiconductor Systems. (1998). ““Jupiter” Global Positioning System

(GPS) Receiver (Part No. TU30-D140-221/231)”. GD003E. Townsend, C.P.; Hamel, M.J.; Sonntag, P.; Trutor, B.; Arms, S.W. (2002).

“Scaleable, wireless web-enabled sensor networks”. Proceedings of SPIE - The International Society for Optical Engineering (pp. 1-9). The International Society for Optical Engineering

US Digital Corporation. (2004). “T2 Incremental Inclinometer”. Rev. 01.20.04.

T2. Winfield, A.F.T.; Holland, O.E. (2000, March). “Application of wireless local

area network technology to the control of mobile robots”. Microprocessors and Microsystems (pp. 597-607)

WIZnet. (2002). “i2Chip W3100A Technical Datasheet v1.3”

76

Appendix A: LOMAC Motor Drive Code '**************************************************************** ' 'Title: motorsl.bas Motor Controller ' 'Author: Douglas Guardino ' 'Compiler: Pic Basic Pro 2.42a ' 'Platform: PIC Microprocessor PIC16F876A @ 20 MHz ' 'Description: This program turns the PIC in to a I2C slave. The ' I2C slave address is read from Port B at the start ' of the program. The PIC outputs a pulse width ' modulated signal on Port C pin 1, based on a ' duty cycle receives from a I2C master. ' 'Credits: The code here is based on microEngineering Lab’s ' I2C slave example, 12cslave.bas available on ' http://www.melabs.com/resources/samples.htm ' '**************************************************************** ' PicBasic Pro I2C slave program - PIC16F877/PIC-X1 define OSC 20 'Tell compiler 20 MHz oscillator is used ' Alias pins scl VAR PORTC.3 ' I2C clock input sda VAR PORTC.4 ' I2C data input ' Define used register flags SSPIF VAR PIR1.3 ' SSP (I2C) interrupt flag BF VAR SSPSTAT.0 ' SSP (I2C) Buffer Full R_W VAR SSPSTAT.2 ' SSP (I2C) Read/Write D_A VAR SSPSTAT.5 ' SSP (I2C) Data/Address CKP VAR SSPCON.4 ' SSP (I2C) SCK Release Control SSPEN VAR SSPCON.5 ' SSP (I2C) Enable SSPOV VAR SSPCON.6 ' SSP (I2C) Receive Overflow Indicator WCOL VAR SSPCON.7 ' SSP (I2C) Write Collision ' Detect ' Allocate RAM datain VAR BYTE ' Data in dataout VAR BYTE[2] ' Data out array address var byte ' Internal address

77

speed var byte ' PWM value temp var byte outgoing var byte x var word servo var word mode var bit I2Caddress var byte trisb = $FF i2caddress = portb >> 1 speed = 0 datain = 0 trisc.2 = 0 HPWM 1, 0, 3767 goto init Disable i2cslave: ' I2C slave subroutine SSPIF = 0 ' Clear interrupt flag IF R_W = 1 Then i2crd ' Read data from us IF BF = 0 Then i2cexit ' Nothing in buffer so exit IF D_A = 1 Then i2cwr ' Data for us (not address) ' Clear the address from the buffer IF SSPBUF != I2Caddress Then i2cexit GoTo i2cexit i2cwr: ' I2C write data to us if mode = 0 Then address = SSPBUF ' set address value mode = 1 GoTo i2cexit endif if mode = 1 Then datain = SSPBUF mode = 0 GoTo i2cexit endif GoTo i2cexit

78

i2crd: ' I2C read data from us SSPBUF = dataout[address] ' Get data from array CKP = 1 ' Release SCL line mode = 0 ' set mode GoTo i2cexit ' That's it i2cexit: if SSPOV = 1 then mode = 0 SSPOV = 0 BF = 0 temp = SSPBUF endif Resume ' Return to main program Enable init: trisa = $ff trisc.0 = 1 trisc.3 = 1 trisc.4 = 1 ' Enable Inturupts and mask all non ssp ones INTCON = %11000000 PIE1 = %00001000 PIE2 = $00 ' Initialize ports and directions ADCON1 = %00000111 ' PORTA to digital ' Initialize I2C slave mode SSPADD = I2Caddress ' Set our address SSPCON2 = 0 ' General call address disabled SSPCON = $36 ' Set to I2C slave with 7-bit address option_reg.5 = 1 option_reg.4 = 0 option_reg.3 = 1 option_reg.2 = 0 option_reg.1 = 0 option_reg.0 = 0 t1con = %00000111

79

On Interrupt GoTo i2cslave GoTo mainloop ' Skip over subroutines mainloop: ' Main program loop if datain != speed then speed = datain HPWM 1, speed, 3767 endif goto mainloop end

80

Appendix B: R/C Interpolator Code '**************************************************************** ' 'Title: motorcon.bas R/C Interpolator Code ' 'Author: Douglas Guardino ' 'Compiler: Pic Basic Pro 2.40 ' 'Platform: PIC Microprocessor PIC16F876A @ 4 MHz ' 'Description: This program uses a PIC to interpret signals from ' a R/C receiver and turns them into duty cycles for ' the motor controllers. The duty cycle is ' transmitted to the motor controllers through the ' I2C bus. The R/C receiver channels are read on ' Port B Pin 0 (Power) and Port B Pin 1 ' (Differential). The I2C bus’s clock pin is Port B ' Pin 3 and the data pin is Port B Pin 2 ' '**************************************************************** ' Pin Aliases scl VAR PORTB.3 ' I2C clock sda VAR PORTB.2 ' I2C data ' Motor Controller I2C slave Addresses motorladdressL CON 2 motorladdressR CON 15 ' RAM alocation outdataL var byte outdataR var byte address var byte controlP var byte controlD var byte controlPold var byte controlDold var byte maxP var byte minP var byte maxD var byte minD var byte intensity var byte diff var byte diffq var byte ' Initialize Variables

81

outdataL = 0 outdataR = 0 controlPold = 0 controlDold = 0 maxP = 0 maxD = 0 minP = 0 minD = 0 intensity = 0 diff = 0 diffq = 0 ADCON1 = %00000111 'Sets the analog pins to digital mode trisa = $FF 'Sets Port A as inputs trisb = $00 'Sets Port B as outputs trisc = $00 'Sets Port C as outputs trisb.2 = 1 'Sets Port B pin 2 as an input trisb.3 = 1 'Sets Port B pin 3 as an input trisb.1 = 1 'Sets Port B pin 1 as an input trisb.0 = 1 'Sets Port B pin 0 as an input ' The program reads two channels from the R/C controller: ' Power and Differential. getspeed: wait01: pause 4 if portb.0 = 1 then wait01 'make sure the pin is in a known ' state pulsin portb.0, 1, controlP 'reads the pulse length for power wait02: if portb.1 = 1 then wait02 'make sure the pin is in a known ' state pulsin portb.1, 1, controlD 'reads the pulse length for

' differential ' adds padding to the last used value to reduce changes due to ' random fluctuations maxP = controlPold + 3 minP = controlPold - 3 maxD = controlDold + 3 minD = controlDold - 3 ' Check to see if there been significant change since the last ' used value. If there was it continues otherwise it goes and ' checks the R/C reciver again. if ( controlP <= maxP ) AND (controlP >= minP) AND ( controlD <= maxD ) AND (controlD >= minD)then

82

goto wait01 endif ' At this point updated the last used value controlPold = controlP controlDold = controlD ' Start of the control algorithm if controlP < 117 then intensity = 0 outdataL = 0 outdataR = 0 goto setspeed endif if controlP > 180 then intensity = 255 goto checkdiff endif intensity = (controlP - 117) * 4 checkdiff: if controlD < 149 then outdataR = intensity if controlD < 103 then outdataL = 0 goto setspeed endif diffq = (149 - controlD) diff = (diffq * 5) if diff > intensity then outdataL = 0 else outdataL = intensity - diff endif goto setspeed endif if controlD > 151 then outdataL = intensity if controlD > 192 then outdataR = 0 goto setspeed endif diffq = (controlD - 151) diff = (diffq * 6) if diff > intensity then outdataR = 0 else outdataR = intensity - diff

83

endif goto setspeed endif outdataR = intensity outdataL = intensity ' The control algorithm has determined the duty cycle for each ' engine and it need to be sent using the I2C bus to the motor ' controllers setspeed: address = 0 wd: i2cwrite sda, scl, motorladdressL, address, [outdataL] pause 70 wd2: i2cwrite sda, scl, motorladdressR, address, [outdataR] pause 70 ' Restarts the process over again goto getspeed

84

Appendix C: GPS Reader Code '**************************************************************** ' 'Title: gpsSlave.c GPS Reader Slave ' 'Author: Douglas Guardino ' 'Compiler: C18 v2.30 ' 'Platform: PIC Microprocessor PIC18F258 @ 40 MHz ' 'Description: This program uses a PIC to read the serial output ' of a GPS module and saves the GPRMC sentence and ' provided it for access over the I2C ' communications. The PIC is an I2C slave. ' '**************************************************************** #include <p18f258.h> #include <delays.h> #include <usart.h> #include <i2c.h> #include <string.h> char usartBuff[80], i2cBuff[80] = "hellol world ", inbuff[20], bufflength = 0, lastchar, temp, lastr = 0, nextw = 0, tag[8] = "$GPRMC,", status = 0; // high interrupts void int_handle (void); #pragma code HIGH_INTERRUPT_VECTOR = 0x8 void high_ISR (void) _asm goto int_handle _endasm #pragma code // this command gets a byte form the USART buffer and puts I in // the receive buffer and increments the end of buffer value void getbyte(void) inbuff[nextw] = ReadUSART(); // gets USART byte nextw ++; // increments the buffer

// index

85

if (nextw >= 20) // checks for buffer wrap around nextw = 0; PIR1bits.RCIF = 0; // Clears USART interrupt flag // interrupt handler // handles the interrupt generat4ed by the an I2C reception #pragma interrupt int_handle void int_handle (void) char length = 0; INTCON = 0; PIR1 = 0; // clears all interrupts // If a Read request is received it transmits the GPS

// sentence stored if (SSPSTATbits.R_W == 1) for(length = 0; length < 80; length++) PIR1bits.SSPIF = 0 ; SSPBUF = i2cBuff[length]; SSPCON1bits.CKP = 1; if(PIR1bits.RCIF) getbyte(); while ( !PIR1bits.SSPIF ); // Handles any other I2C conditions, by ignoring them if (SSPSTATbits.D_A == 1) temp = SSPBUF; if (SSPBUF != 0x0F) temp = SSPBUF; if (SSPCON1bits.SSPOV == 1) SSPCON1bits.SSPOV = 0; SSPSTATbits.BF = 0; temp = SSPBUF; SSPCON1bits.CKP = 1; // enables the interrupt INTCON = 0b11000000; // This command gets a byte out of the receive buffer If there // nothing in the buffer it wait for the next byte to be received // It then updates the buffer indexes. int getlast(void) char current; current = lastr; lastr++;

86

if (lastr >= 20) lastr = 0; // If the buffer is empty wait for data to be received if (current == nextw) while(!DataRdyUSART()); getbyte(); // Returns the last byte received return inbuff[current]; void main (void) // Initialize the USART port OpenUSART( USART_TX_INT_OFF & // TX interrupt off USART_RX_INT_OFF & // RX interrupt off USART_ASYNCH_MODE & // Asynchronous mode USART_EIGHT_BIT& // 8-Bit USART_CONT_RX & // Continuous receive USART_BRGH_LOW, // Low Baud rate formula 129); // set approximately 4800 bps // Initialize the I2C port in slave mode OpenI2C( SLAVE_7, SLEW_ON); // I2C master mode 100kHz mode SSPADD = 0x0F; // Sets the slave address to 0x0F TRISC = 0xFF; SSPCON1bits.CKP = 1; memset(usartBuff, 0, 80); // clears the incoming buffer // Initializes the interrupt setting, setting it to

// interrupt on I2C receive. INTCON = 0b11000000; INTCON2 = 0; INTCON3 = 0; PIE1 = 0b00001000; PIE2 = 0; // Repeats this code endlessly // This code searches for the GPRMC sentence tag // It compares the incoming serial data to a known string

// to find the GPRMC tag it then moves the rest of the // sentence into a receiving buffer till the end of // sentence character is received. It then copies it to the // output buffer.

while(1) lastchar = 0; status = 0;

87

while(status != 7) lastchar = getlast(); if(tag[status] == lastchar) status++; else status = 0; bufflength = 0; while(lastchar != 10) lastchar = getlast(); usartBuff[bufflength] = lastchar; bufflength++; usartBuff[bufflength] = 0; strcpy( i2cBuff, usartBuff); memset(usartBuff, 0, 80);

88

Appendix D: Inclinometer Slave Code '**************************************************************** ' 'Title: incloslave.c Inclinometer Slave ' 'Author: Douglas Guardino ' 'Compiler: C18 v2.30 ' 'Platform: PIC Microprocessor PIC18F258 @ 40 MHz ' 'Description: This program uses a PIC to read quadrature signal ' outputted by the inclinometer. The PIC has an ' internal counter that is initialized at start up. ' This counter can be accessed over the I2C bus. ' The PIC is set up as an I2C slave. The system will ' Interrupt on changed in either Port B pins 4 and 5 ' these pins are hooked to the inclinometer. ' '**************************************************************** #include <p18f258.h> #include <i2c.h> int incl = 0; // set the angle to 0 unsigned char * inclpt; char temp, BLast = 0, QuadTable[4][4] = 0,-1, 1, 0, 1, 0, 0,-1, -1, 0, 0, 1, 0, 1,-1, 0; // The above table tells the program how to increment the counter // based on the last state and the current state of the pins. // high interupts void int_handle (void); #pragma code HIGH_INTERRUPT_VECTOR = 0x8 void high_ISR (void) _asm goto int_handle _endasm #pragma code #pragma interrupt int_handle

89

void int_handle (void) char BNow; BNow = PORTB & 0b00110000; //this masks the unused bits BNow = BNow >> 4; //this moves the used bit to LSB incl += QuadTable[BNow][BLast]; // This them increment the // the counter based on the

// table BLast = BNow; // updates the last state INTCON = 0b10001000; // initialize interrupt void main (void) // initialize parameters

char length = 0; BLast = PORTB & 0b00110000; // gets initial state BLast = BLast >> 4; OpenI2C( SLAVE_7, SLEW_ON); SSPADD = 0x08; // sets the I2C slave address to 0x08 TRISC = 0xFF; TRISB = 0xFF; SSPCON1bits.CKP = 1; inclpt = (unsigned char *)&incl; // initialize the pointer // initialize interrupt INTCON = 0b10001000; INTCON2 = 0; INTCON3 = 0; PIE1 = 0b00000000; PIE2 = 0; // repeat this code constantly // this code check to see it there has been a read request // on the I2C for the inclinometer angle it then transmits // the angle back. while (1) if(PIR1bits.SSPIF) PIR1 = 0; if (SSPSTATbits.R_W == 1) for(length = 0; length < 2; length++) PIR1bits.SSPIF = 0 ; SSPBUF = inclpt[length]; SSPCON1bits.CKP = 1; while ( !PIR1bits.SSPIF ); if (SSPSTATbits.D_A == 1) temp = SSPBUF; if (SSPBUF != 0x0F)

90

temp = SSPBUF; if (SSPCON1bits.SSPOV == 1) SSPCON1bits.SSPOV = 0; SSPSTATbits.BF = 0; temp = SSPBUF; SSPCON1bits.CKP = 1;

91

Appendix E: PICNIC Code '**************************************************************** ' 'Title: picnici2c.c PICNIC code ' 'Author: Douglas Guardino ' 'Compiler: C18 v2.30 ' 'Platform: PIC Microprocessor PIC18F458 @ 40 MHz ' 'Description: This program uses a PIC as the central processing ' unit of a system of sensors. It gets analog ' information on analog channels 0 – 6. It also gets ' GPS and Inclination over the I2C bus from other ' devices. It also uses the I2C buss to communicate ' with the IIM710A. ' '**************************************************************** #include <p18f458.h> #include <delays.h> #include <usart.h> #include <i2c.h> #include <string.h> #include <stdlib.h> #include <adc.h> #include <timers.h> // initialize global parameters unsigned char status, buffer[80], temp[10]; char charbuff[10], ackstat = 0; int doug, time = 0, timelast; unsigned long before, after; rom char initStMsg[] = "Initilazation Status "; rom char socketInitStMsg[] = "Socket Initilazation Status "; rom char WaitConectMsg[] = "Waiting for connection"; rom char conectEstabMsg[] = "Connection Established"; rom char welcomeMsg[] = "Good Morning"; // high interupts void int_handle (void); #pragma code HIGH_INTERRUPT_VECTOR = 0x8 void high_ISR (void) _asm

92

goto int_handle _endasm #pragma code // this interrupt is generated every time Timer0 overflows. // This happens every millisecond. This handler re-setup the // timer and increments millisecond counter. #pragma interrupt int_handle void int_handle (void) WriteTimer0(55535); time++; INTCON = 0b10100000; // this command was written to transmit data over the I2C buss // it takes the control address of the device, a 2-byte address, // a pointer and the number of bytes to be transmitted. void i2cTx( unsigned char control, unsigned char addressHigh, unsigned char addressLow, unsigned char *array, unsigned char length) unsigned char count; IdleI2C(); StartI2C(); while ( SSPCON2bits.SEN ); control = control & 0xFE; WriteI2C ( control); IdleI2C(); WriteI2C ( addressHigh); IdleI2C(); WriteI2C ( addressLow); for(count = 0; count < length; count++) IdleI2C(); WriteI2C ( array[count]); IdleI2C(); StopI2C(); while ( SSPCON2bits.PEN ); // this command was written to receive data over the I2C buss // it takes the control address of the device, a 2-byte address, // a pointer and the number of bytes to be transmitted. // This command transmits the address before requesting a read. unsigned char * i2cRx( unsigned char control, unsigned char addressHigh, unsigned char addressLow,

93

unsigned char *array, unsigned char length) unsigned char count; IdleI2C(); StartI2C(); while ( SSPCON2bits.SEN ); control = control & 0xFE;

WriteI2C ( control); IdleI2C(); WriteI2C (addressHigh); IdleI2C(); WriteI2C ( addressLow); IdleI2C(); StopI2C(); while ( SSPCON2bits.PEN ); control = control | 0x01; IdleI2C(); StartI2C(); while ( SSPCON2bits.SEN ); WriteI2C ( control); SSPCON2bits.RCEN = 1; for(count = 0; count < length; count++) IdleI2C(); array[count] = ReadI2C(); if (count == length -1) NotAckI2C(); else AckI2C(); IdleI2C(); StopI2C(); while ( SSPCON2bits.PEN ); return(array); // This command initializes the IIM7010A with the commented // values unsigned char InitWiznet( unsigned char control)

94

unsigned char data; // initilise IINCHIP // Gatway Address buffer[0] = 192; //80 buffer[1] = 168; //81 buffer[2] = 1; //82 buffer[3] = 1; //83 // Subnet Mask buffer[4] = 255; //84 buffer[5] = 255; //85 buffer[6] = 255; //86 buffer[7] = 0; //87 //MAC Address buffer[8] = 0x00; //88 buffer[9] = 0xA0; //89 buffer[10] = 0x24; //8A buffer[11] = 0xBB; //8B buffer[12] = 0xD8; //8C buffer[13] = 0x6A; //8D // IP Address buffer[14] = 192; //8E buffer[15] = 168; //8F buffer[16] = 1; //90 buffer[17] = 50; //91 // Initial Retry Timer - value buffer[18] = 0x03; //92 100ms buffer[19] = 0xE8; //93 //Retry Count buffer[20] = 255; //94 // RX data Memory size buffer[21] = 0b000011; //95 8kb to ch 0 // TX data Memory size buffer[22] = 0b000011; //96 8kb to ch 0 //Write all that to the IINCHIP i2cTx( control, 0x00, 0x80, buffer, 23); buffer[0] = 0x01; //Sends the initialze command i2cTx( control, 0x00, 0x00, buffer, 1);

95

//Checks status of initilazation i2cRx( control, 0x00, 0x04, &data, 1); //Returns the result of the initilazation return(data); // this command initializes ch0 to commented parameters. unsigned char initSocketCh0( unsigned char control, unsigned char hport, unsigned char lport) unsigned char data; // set SOPR register data = 0x01; //TCP communications i2cTx( control, 0x00, 0xA1, &data, 1); // set SPR registers, sets the port to listen on buffer[0] = hport; buffer[1] = lport; i2cTx( control, 0x00, 0xAE, buffer, 2); // set TOSR register to 1 // data alreadyt = 1 so it will not be set again i2cTx( control, 0x00, 0xB1, &data, 1); // set transmisoin pointers memset(buffer, 0, 10); // clears the first 10 buffer byes // set C0_TW_PR 01 - 04 to 0 // set C0_TR_PR 01 - 04 to 0 i2cTx( control, 0x00, 0x40, buffer, 8); // set C0_TA_PR 01 - 04 to 0 i2cTx( control, 0x00, 0x18, buffer, 4); // initilise socket data = 0b00000010; i2cTx( control, 0x00, 0x00, &data, 1); //clear interupts data = 0xFF; i2cTx( control, 0x00, 0x08, &data, 1); //check if socket initilized i2cRx( control, 0x00, 0x04, &data, 1); return(data); // this command outputs a string of a defined length on the // serial port, which an LCD screen is connected

96

void stringUARTS(char * string, unsigned char length) unsigned char x; for( x = 0; x < length; x++) while (BusyUSART()); WriteUSART(string[x]); return; // this command receives data from the IIM7010A and displays it // on the LCD screen int reciveData(unsigned char control)

unsigned char C0_RW_PR[4], C0_RR_PR[4], data, adhigh, adlow, rxlength = 0;

unsigned int counter, rstart, rend; memset(C0_RW_PR, 0, 4); memset(C0_RR_PR, 0, 4); // get pointers for recived data //check shadow pointer C0_SRW_PR i2cRx( control, 0x01, 0xE0, &data, 1); //wait 20 clock cycles Delay10TCYx(2); //Get the C0_RW_PR pointers i2cRx( control, 0x00, 0x10, C0_RW_PR, 4); //check shadow pointer C0_SRR_PR i2cRx( control, 0x01, 0xE1, &data, 1); //wait 20 clock cycles Delay10TCYx(2); //Get the C0_RR_PR pointers i2cRx( control, 0x00, 0x14, C0_RR_PR, 4); //Convert pointer into offsets rstart = C0_RR_PR[2]; rstart = rstart << 8; rstart &= 0x1F00; rstart += C0_RR_PR[3]; rend = C0_RW_PR[2] ; rend = rend << 8; rend &= 0x1F00;

97

rend += C0_RW_PR[3]; //Find lenght of information in buffer if(rend > rstart) counter = rend - rstart; data = 0; else counter = (rend + 0x1FFF) - rstart; data = 1; if(rend == rstart) return(0); rxlength = 0; while(counter) adhigh = rstart >> 8; adhigh += 0x60; adlow = rstart & 0x00FF; if( counter < 80) rxlength = counter; else rxlength = 80; if ( (rstart + rxlength) > 0x1FFF) rxlength = 0x2000 - rstart; i2cRx( control, adhigh, adlow, buffer, rxlength); stringUARTS((char *)buffer, rxlength); rstart += rxlength; if (rstart > 0x1FFF) rstart -= 0x2000; counter -= rxlength; i2cTx( control, 0x00, 0x14, C0_RW_PR, 4); data = 0b01000000; i2cTx( control, 0x00, 0x00, &data, 1); return(1); // This command transmits data using the IIM7010A void trasmitData( unsigned char control, unsigned char * string, unsigned char length)

98

unsigned char C0_TW_PR[4], data, adhigh, adlow,

txlength, offset = 0;

unsigned char * TW; unsigned int counter, tstart, tend; unsigned long C0_TW; char y; TW = (unsigned char *)&C0_TW; // get pointers for received data //check shadow pointer C0_STW_PR i2cRx( control, 0x01, 0xF0, &data, 1); //wait 20 clock cycles Delay10TCYx(2); //Get the C0_TW_PR pointers i2cRx( control, 0x00, 0x40, C0_TW_PR, 4); y = 3; for(y = 3; y >= 0; y--) TW[y] = C0_TW_PR[3 - y]; before = C0_TW; C0_TW += length; after = C0_TW; //Convert pointer into offsets tstart = C0_TW_PR[2]; tstart = tstart << 8; tstart &= 0x1F00; tstart += C0_TW_PR[3]; while(length) adhigh = tstart >> 8; adhigh += 0x40; adlow = tstart & 0x00FF; if ( (tstart + length) > 0x1FFF) txlength = 0x2000 - tstart; else txlength = length;

99

i2cTx( control, adhigh, adlow, string + offset, txlength);

tstart += txlength; if (tstart > 0x1FFF) tstart -= 0x2000; length -= txlength; offset += txlength; for(y = 3; y >= 0; y--) C0_TW_PR[y]= TW[3 - y] ; // Update the C0_TW_PR pointers i2cTx( control, 0x00, 0x40, C0_TW_PR, 4); // Execute a send comand data = 0b00100000; i2cTx( control, 0x00, 0x00, &data, 1); return; // this command converts an integer saving a 4 significant digit // 3 decimal place number into an ASCII string char * asciAcell(int value, char * string) int letter; if (value < 0) value = value * -1; string[0] = 45; else string[0] = 32; letter = value / 1000; value = value - (1000 * letter); string[1] = letter + 48; string[2] = 46; letter = value / 100; value = value - (100 * letter); string[3] = letter + 48; letter = value / 10; value = value - (10 * letter); string[4] = letter + 48; string[5] = value + 48; return(string); // This command gets the acceleration from specified channel and // places it in specified array.

100

char * getacell(char chan, char * outputB) int acell; unsigned int acell_16 = 0 ; char x; short long voltage; if( chan == 0) SetChanADC(ADC_CH0); if( chan == 1) SetChanADC(ADC_CH1); if( chan == 2) SetChanADC(ADC_CH2); if( chan == 3) SetChanADC(ADC_CH3); Delay10TCYx(7); for( x = 0; x < 16; x++) ConvertADC(); while(BusyADC()); acell = ReadADC(); acell_16 += acell; acell = acell_16 >> 4; doug = acell; acell -= 511; voltage = acell; voltage = voltage * 1000; voltage = voltage / 204; //205 acell = voltage; asciAcell(acell, outputB); outputB[6] = 32; if( chan == 0) outputB[7] = 90; // “Z” if( chan == 1) outputB[7] = 89; // “Y” if( chan == 2) outputB[7] = 90; // “Z” if( chan == 3) outputB[7] = 88; // “X” outputB[8] = 13; // CR outputB[9] = 10; // LF return(outputB); // this command read the remaining analog channels (digital // compass and optional one) and puts the results in a string char * getanalog(char * outputB) int NS = 0, EW = 0, power = 0, NS16 = 0, EW16 = 0,

power16 = 0, x; char stringL; short long voltage; SetChanADC(ADC_CH4);

101

Delay10TCYx(7); for( x = 0; x < 16; x++) ConvertADC(); while(BusyADC()); NS = ReadADC(); NS16 += NS; SetChanADC(ADC_CH5); Delay10TCYx(7); for( x = 0; x < 16; x++) ConvertADC(); while(BusyADC()); EW = ReadADC(); EW16 += EW; NS = NS16 >> 4; EW = EW16 >> 4; SetChanADC(ADC_CH6); Delay10TCYx(7); for( x = 0; x < 16; x++) ConvertADC(); while(BusyADC()); power = ReadADC(); power16 += power; power = power16 >> 4; itoa( NS, charbuff); strcpy(outputB, charbuff); stringL = strlen(outputB); outputB[stringL] = 32; outputB[stringL+1] = 0; itoa( EW, charbuff); strcat(outputB, charbuff); stringL = strlen(outputB); outputB[stringL] = 32; outputB[stringL+1] = 0; voltage = power; voltage = voltage * 1000; voltage = voltage / 205; power = voltage; asciAcell(power, charbuff); charbuff[6] = 32; charbuff[7] = 86; charbuff[8] = 0; strcat(outputB, charbuff); stringL = strlen(outputB); outputB[stringL] = 32; outputB[stringL+1] = 0; return (outputB);

102

void main (void) unsigned char wiznet = 0b10101010, length; unsigned int y; int pitch, roll; // initialize PIC peripherals OpenUSART( USART_TX_INT_OFF & // TX interrupt off USART_RX_INT_OFF & // RX interrupt off USART_ASYNCH_MODE & // Asynchronous mode USART_EIGHT_BIT& // 8-Bit USART_CONT_RX & // Continuous receive USART_BRGH_LOW, // Low Baud rate formula 64); // set approximately 9.6 kbs // initialize the I2C OpenI2C( MASTER, SLEW_ON); // I2C master mode 100kHz mode SSPADD = 99;

// initialize the analog channels OpenADC( ADC_FOSC_64 & ADC_RIGHT_JUST & ADC_8ANA_0REF, ADC_CH0 & ADC_INT_OFF); TRISA = 0xFF; TRISE = 0x0F;

// initialize the timer 0 OpenTimer0( TIMER_INT_OFF & T0_16BIT & T0_SOURCE_INT & T0_EDGE_FALL & T0_PS_1_1 ); TRISD = 0xFF; LATD = 255; WriteUSART( 12 ); // 12 clears the LCD screen // wait for screen to finish clearing Delay10KTCYx(50); while (BusyUSART()); putrsUSART( welcomeMsg); // wait .5 sec and then clear screen Delay10KTCYx(250);

103

Delay10KTCYx(250); WriteUSART( 12 ); // wait for screen to finish clearing Delay10KTCYx(50); status = 0; // initialize the IINCHIP status = InitWiznet(wiznet); // clear buffer memset(buffer, 0, 80); // out puts result of initialization to LCD // a result of 1 means the system initialized while (BusyUSART()); putrsUSART( initStMsg ); while (BusyUSART()); putsUSART( btoa(status, charbuff) ); while (BusyUSART()); WriteUSART( 10 ); // this code continually repeats. while(1) // socket initialization // setting ch0 listen on port 23 for a connection status = initSocketCh0( wiznet, 0, 23); // clear buffer memset(buffer, 0, 10); // out puts result of initialization to LCD // a result of 2 means the socket initializes while (BusyUSART()); putrsUSART( socketInitStMsg ); while (BusyUSART()); putsUSART( btoa(status, charbuff)); while (BusyUSART()); WriteUSART( 10 ); // now listen for a connection wait for a connection; buffer[0] = 0b00001000; i2cTx( wiznet, 0x00, 0x00, buffer, 1); while (BusyUSART()); putrsUSART( WaitConectMsg); while (BusyUSART()); WriteUSART( 10 );

104

// check the Socket State Register for ch0 // a value of 0x06 means a connection has been

// established while (status != 0x06) // Delay10KTCYx(1); // while not connected display the accelerations for

// calibration getacell(0, charbuff); charbuff[8] = 13; while (BusyUSART()); WriteUSART(32); stringUARTS(charbuff, 9);

getacell(1, charbuff); charbuff[8] = 13; while (BusyUSART()); WriteUSART(32); stringUARTS(charbuff, 9); getacell(2, charbuff); charbuff[8] = 13; while (BusyUSART()); WriteUSART(32); while (BusyUSART()); WriteUSART(32); stringUARTS(charbuff, 9);

getacell(3, charbuff); charbuff[8] = 13; while (BusyUSART()); WriteUSART(32); while (BusyUSART()); WriteUSART(32); stringUARTS(charbuff, 9); // displays the other analog channel

// information getanalog((char *) buffer);

length = strlen((char *)buffer); while (BusyUSART()); WriteUSART(32); while (BusyUSART()); WriteUSART(32); stringUARTS((char *)buffer, length); // reads the inclination and displays it i2cRx( 0x08, 0x00, 0xA0, (

unsigned char *)&pitch, 2); itoa( pitch, (char *)buffer);

105

length = strlen((char *)buffer); buffer[length] = 13; length ++; buffer[length] = 0; stringUARTS((char *)buffer, length); // wait .2 sec Delay10KTCYx(200); WriteUSART( 12 ); // wait for screen to finish clearing Delay10KTCYx(60); // check to see if there is a connection i2cRx( wiznet, 0x00, 0xA0, &status, 1); // connection established while (BusyUSART()); putrsUSART( conectEstabMsg); // wait 1 sec and then clear screen Delay10KTCYx(250); Delay10KTCYx(250); Delay10KTCYx(250); Delay10KTCYx(250); WriteUSART( 12 ); // wait for screen to finish clearing Delay10KTCYx(50); // enables the interrupt for the timer INTCON = 0b10100000; // while the connection is open do all this stuff while (status == 0x06) // check the receive buffer to see if there is

// any incoming data for the LCD screen and // output it (disabled) // reciveData(wiznet); // make sure the millisecond counter is within

// the limit if(time > 1000) time = 0; // captures the millisecond counter timelast = time; // reduces the number of transmissions // it transmits the non GPS data every

// 40 milliseconds

106

if ( timelast % 40 == 0) getacell(0, charbuff); charbuff[8] = 32; charbuff[9] = 0; strcpy((char * )buffer, charbuff); getacell(1, charbuff); charbuff[8] = 32; charbuff[9] = 0; strcat((char * )buffer, charbuff); getacell(2, charbuff); charbuff[8] = 32; charbuff[9] = 0; strcat((char * )buffer, charbuff); getacell(3, charbuff); charbuff[8] = 32; charbuff[9] = 0; strcat((char * )buffer, charbuff); length = strlen((char *) buffer); trasmitData(wiznet,buffer,length); getanalog ((char *)buffer); i2cRx( 0x08, 0x00, 0xA0, (

unsigned char *)&pitch, 2); itoa( pitch, charbuff); strcat((char * )buffer, charbuff); length = strlen((char *)buffer); buffer[length] = 32; length++; buffer[length] = 0; length++; itoa( timelast, charbuff); strcat((char * )buffer, charbuff); length = strlen((char *)buffer); if(timelast == 1000) buffer[length] = 32; length ++; else buffer[length] = 10; length ++; buffer[length] = 13; length ++; trasmitData(wiznet,buffer,length);

107

// transmit the GPS data once a second and // reset the millisecond counter

if( timelast == 1000) // 275 // access the GPS and get last update i2cRx( 0x0F, 0x00, 0x00, buffer, 80); // transmit the last updata length = strlen((char *)buffer); trasmitData(wiznet,buffer, length); time -= 1000; // Check the current connection status i2cRx( wiznet, 0x00, 0xA0, &status, 1);

108

Appendix F: Motor Driver Schematic

109

Appendix G: R/C Interpolator Schematic

110

Appendix H: Power and GPS Board Schematic

111

Appendix I: Accelerometer Board Schematic

112

Appendix J: PICNIC Board Schematic

113

Appendix K:Florida Tech Campus (Florida Institute of Technology, 2004)

114

Appendix L: Boat Test - Acceleration Data

115

Appendix M: Car Test 1 – Acceleration

116

Appendix N: Car Test 1 - Acceleration and Inclinometer

117

Appendix O: Car Test 2 - Accelerations and Inclination

118

Appendix P: Car Test 3 - Acceleration and Inclination

119

120