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

Douglas Guardin o

Digitally signed by Douglas Guardino DN: CN = Douglas Guardino, C = US Reason: I am the author of this document Date: 2004.06.26 17:55:08 -04'00'

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 3.1 3.2 3.3 3.4 3.5 3.6

TESTING AND RESULTS ...................................................................................... 46 FALL 2003 POOL TEST ................................................................................................. 46 SPRING 2004 POOL TEST .............................................................................................. 47 CAR TEST 1 .................................................................................................................. 49 CAR TEST 2 .................................................................................................................. 52 CAR TEST 3 .................................................................................................................. 56 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, lowcost 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, fullduplex 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)).

•

RMC

$GPRMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,ddmmyy,x.x,a*hh RMC = Recommended Minimum Specific GPS/TRANSIT Data 1 2 3 4 5 6 7 8 9 10 11 12

= UTC of position fix = Data status (V=navigation receiver warning) = Latitude of fix = N or S = Longitude of fix = E or W = Speed over ground in knots = Track made good in degrees True = UT date = Magnetic variation degrees (Easterly var. subtracts from true course) = E or W = Checksum

Figure 2.7: RMC NMEA Tag Definition (NMEA, 2004) Appendix C contains the code that reads the serial GPS sentences, moves the appropriate sentence to the outgoing string buffer, and handles the I2C slave transmission. The string is long enough that it is likely that a serial byte or bytes received from the GPS will be in the incoming buffer while the I2C slave is transmitting the outgoing string. To avoid data loss, after each byte is loaded into the I2C module for transmission, the program checks the serial buffer. If there is data in the buffer, it is moved to a second buffer from which serial data can be read upon 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

Channel A

Channel A

Channel B

Channel B

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 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.000 001 600 s

0.025 µs 1.60 µs

0.000 017 600 s

17.6

µs

0.000 036 800 s

30.5

µs

0.001 000 000 s

1000

µs

0.005 700 000 s

5700

µs

Oscillator TAD time 10-bit A/D conversion time 10-bit A/D conversion with delay for channel changing Max time for shortest period digital acquisition 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 oneway 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. . Burland, Travis & Mark Cencer & Patrick Hatton. (2003). “LOMAC LittoralOperation 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 SingleSupply 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. . 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 ' Alias pins scl VAR sda VAR

'Tell compiler 20 MHz oscillator is used

PORTC.3 PORTC.4

' I2C clock input ' I2C data input

' Define used register flags SSPIF VAR PIR1.3 BF VAR SSPSTAT.0 R_W VAR SSPSTAT.2 D_A VAR SSPSTAT.5 CKP VAR SSPCON.4 SSPEN VAR SSPCON.5 SSPOV VAR SSPCON.6 Indicator WCOL VAR SSPCON.7

' Allocate RAM datain VAR dataout VAR address var

' ' ' ' ' ' '

SSP SSP SSP SSP SSP SSP SSP

(I2C) (I2C) (I2C) (I2C) (I2C) (I2C) (I2C)

interrupt flag Buffer Full Read/Write Data/Address SCK Release Control Enable Receive Overflow

' SSP (I2C) Write Collision ' Detect

BYTE BYTE[2] byte

' Data in ' Data out array ' Internal address

77

speed temp outgoing x servo mode I2Caddress

var var var var var var var

byte byte byte word word bit byte

' PWM value

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: if mode = 0 Then address = SSPBUF mode = 1 GoTo i2cexit endif

' I2C write data to us

' set address value

if mode = 1 Then datain = SSPBUF mode = 0 GoTo i2cexit endif GoTo i2cexit

78

i2crd:

' I2C read data from us

SSPBUF = dataout[address] CKP = 1 mode = 0

' Get data from array ' Release SCL line ' set mode

GoTo i2cexit

' That's it

i2cexit: if

SSPOV = 1 then mode = 0 SSPOV = 0 BF = 0 temp = SSPBUF

endif Resume Enable

' Return to main program

init: trisa = trisc.0 trisc.3 trisc.4

$ff = 1 = 1 = 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 sda

VAR VAR

PORTB.3 PORTB.2

' Motor Controller I2C slave Addresses motorladdressL CON 2 motorladdressR CON 15 ' RAM alocation outdataL outdataR address controlP controlD controlPold controlDold maxP minP maxD minD intensity diff diffq

var var var var var var var var var var var var var var

byte byte byte byte byte byte byte byte byte byte byte byte byte byte

' Initialize Variables

81

' I2C clock ' I2C data

outdataL = 0 outdataR = 0 controlPold = 0 controlDold = 0 maxP = 0 maxD = 0 minP = 0 minD = 0 intensity = 0 diff = 0 diffq = 0 ADCON1 = %00000111 trisa = $FF trisb = $00 trisc = $00 trisb.2 = 1 trisb.3 = 1 trisb.1 = 1 trisb.0 = 1

'Sets 'Sets 'Sets 'Sets 'Sets 'Sets 'Sets 'Sets

the analog pins to Port A as inputs Port B as outputs Port C as outputs Port B pin 2 as an Port B pin 3 as an Port B pin 1 as an Port B pin 0 as an

digital mode

input input input input

' The program reads two channels from the R/C controller: ' Power and Differential. getspeed: wait01: pause 4 if portb.0 = 1 then wait01 pulsin portb.0, 1, controlP wait02: if portb.1 = 1 then wait02 pulsin portb.1, 1, controlD

'make sure the pin is in a known ' state 'reads the pulse length for power

'make sure the pin is in a known ' state '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 = minP) 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 #include #include #include #include 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) nextw = 0; PIR1bits.RCIF = 0;

// checks for buffer wrap around // 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 #include 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 #include #include #include #include #include #include #include



// 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; buffer[1] = 168; buffer[2] = 1; buffer[3] = 1;

//80 //81 //82 //83

// Subnet buffer[4] buffer[5] buffer[6] buffer[7]

//84 //85 //86 //87

Mask = 255; = 255; = 255; = 0;

//MAC Address buffer[8] = 0x00; buffer[9] = 0xA0; buffer[10] = 0x24; buffer[11] = 0xBB; buffer[12] = 0xD8; buffer[13] = 0x6A;

//88 //89 //8A //8B //8C //8D

// IP Address buffer[14] = 192; buffer[15] = 168; buffer[16] = 1; buffer[17] = 50;

//8E //8F //90 //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; 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; 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