Upload
dangdien
View
218
Download
3
Embed Size (px)
Citation preview
Design of Sensor and Wireless Data Acquisition
System For Field Testing of Hull Models
by
Douglas John Guardino
Bachelor of Science Ocean Engineering
Florida Institute of Technology 2004
A thesis submitted to the College of Engineering at
Florida Institute of Technology in partial fulfillment of the requirements
for the degree of
Masters of Science in
Ocean Engineering
Melbourne, Florida July, 2004
We the undersigned committee hereby approve the attached thesis
Design of Sensor and Wireless Data Acquisition System For Field Testing of Hull Models
by
Douglas John Guardino
________________________________ Eric D. Thosteson, Ph.D., P.E. Assistant Professor Ocean Engineering and Oceanography ________________________________ Andrew Zborowski, Ph.D. Professor and Program Chair Ocean Engineering ________________________________ Hector Gutierrez, Ph.D., P.E. Associate Professor Mechanical Engineering
Abstract Title : Design of Sensor and Wireless Data Acquisition System
For Field Testing of Hull Models
Author: Douglas John Guardino
Committee Chair: Eric D. Thosteson, Ph.D., P.E.
This paper describes the design and testing of a group of sensor and
communication systems based on Microchip’s PIC family of microcontrollers.
Analog and digital sensor data is read using multiple microcontrollers networked
using I2C. An iinChip module interfaced to the sensor systems allows data to be
sent from a remote location using TCP/IP and wireless Ethernet (802.11b). The
paper also describes a motor control system designed for use on a model hull
known as the LOMAC. These systems were designed to be implemented on the
LOMAC model to reconstruct the motions of the model hull under natural wave
conditions.
The sensor systems have successfully gathered data from a variety of sensors
including GPS, a digital compass, accelerometers, and an inclinometer. The
system is remotely accessed over the wireless Ethernet connection using Telnet,
providing data at near real-time. During testing it was found that the
iii
accelerometers performed with approximately a 0.04G noise band, with hard
motions being readily apparent in the data record. It was also found that the
inclinometer responds to the acceleration as well as static tilt, which will require
post-processing for interpretation. The results indicate that much of the analog
data would benefit from additional signal conditioning.
iv
Table of Contents ABSTRACT..................................................................................................................................III TABLE OF CONTENTS...............................................................................................................V LIST OF FIGURES ................................................................................................................... VII LIST OF TABLES ....................................................................................................................VIII ACKNOWLEDGEMENT........................................................................................................... IX DEDICATION................................................................................................................................X 1.0 INTRODUCTION....................................................................................................... 1
1.1 GOALS ........................................................................................................................... 1 1.2 BACKGROUND................................................................................................................ 2
1.2.1 LOMAC .................................................................................................................... 3 1.2.2 Wireless Data Acquisition ........................................................................................ 5 1.2.3 TCP/IP Communications Overview........................................................................ 13 1.2.4 Pic Basic Pro and PIC C18.................................................................................... 15
1.3 SCOPE .......................................................................................................................... 17 2.0 SYSTEMS.................................................................................................................. 19
2.1 LOMAC DRIVE SYSTEMS............................................................................................ 19 2.1.1 LOMAC Motor Driver............................................................................................ 20 2.1.2 R/C Interpreter ....................................................................................................... 23
2.2 DATA ACQUISITION AND COMMUNICATION SYSTEMS ................................................. 26 2.2.1 GPS Reader ............................................................................................................ 28 2.2.2 Inclinometer System................................................................................................ 30 2.2.3 Digital Compass ..................................................................................................... 33 2.2.4 Accelerometers ....................................................................................................... 34 2.2.5 IIM7010A................................................................................................................ 39 2.2.6 PICNIC................................................................................................................... 41
3.0 TESTING AND RESULTS ...................................................................................... 46 3.1 FALL 2003 POOL TEST ................................................................................................. 46 3.2 SPRING 2004 POOL TEST.............................................................................................. 47 3.3 CAR TEST 1 .................................................................................................................. 49 3.4 CAR TEST 2 .................................................................................................................. 52 3.5 CAR TEST 3 .................................................................................................................. 56 3.6 ENGINE POWER TEST ................................................................................................... 60
4.0 DISCUSSION ............................................................................................................ 63 5.0 CONCLUSIONS AND RECOMMENDATIONS .................................................. 71 REFERENCES............................................................................................................................. 75 APPENDIX A: LOMAC MOTOR DRIVE CODE................................................................... 77 APPENDIX B: R/C INTERPOLATOR CODE......................................................................... 81 APPENDIX C: GPS READER CODE....................................................................................... 85
v
APPENDIX D: INCLINOMETER SLAVE CODE .................................................................. 89 APPENDIX E: PICNIC CODE................................................................................................... 92 APPENDIX F: MOTOR DRIVER SCHEMATIC.................................................................. 109 APPENDIX G: R/C INTERPOLATOR SCHEMATIC ......................................................... 110 APPENDIX H: POWER AND GPS BOARD SCHEMATIC................................................. 111 APPENDIX I: ACCELEROMETER BOARD SCHEMATIC .............................................. 112 APPENDIX J: PICNIC BOARD SCHEMATIC..................................................................... 113 APPENDIX K:FLORIDA TECH CAMPUS ........................................................................... 114 APPENDIX L: BOAT TEST - ACCELERATION DATA..................................................... 115 APPENDIX M: CAR TEST 1 – ACCELERATION............................................................... 116 APPENDIX N: CAR TEST 1 - ACCELERATION AND INCLINOMETER...................... 117 APPENDIX O: CAR TEST 2 - ACCELERATIONS AND INCLINATION ........................ 118 APPENDIX P: CAR TEST 3 - ACCELERATION AND INCLINATION........................... 119
vi
List of Figures Figure 1.1: LOMAC Model Hull ............................................................................ 3 Figure 1.2: System Block Diagram......................................................................... 4 Figure 2.1: LOMAC Drive System Diagram........................................................ 19 Figure 2.2: LOMAC Jet Drive System ................................................................. 20 Figure 2.3: Motor Driver Board............................................................................ 22 Figure 2.4: Data Acquisition and Communication System .................................. 26 Figure 2.5: Sensor System Board Diagram........................................................... 27 Figure 2.6: GPS Reader System Diagram............................................................. 28 Figure 2.7: RMC NMEA Tag Definition (NMEA, 2004) .................................... 29 Figure 2.8: Inclinometer System Diagram............................................................ 30 Figure 2.9: Quadrature Signal............................................................................... 31 Figure 2.10: Digital Compass System Diagram ................................................... 33 Figure 2.11: Heading Geometry ........................................................................... 34 Figure 2.12: Microchip Instrumentation Amplifier (Microchip, 2004)................ 37 Figure 3.1: Boat Test - Acceleration Data ............................................................ 48 Figure 3.2: Car Test Vehicle................................................................................. 49 Figure 3.3: Florida Tech Campus ......................................................................... 50 Figure 3.4: Car Test 1 – Acceleration................................................................... 51 Figure 3.5: Car Test 1 - Acceleration and Inclinometer ....................................... 52 Figure 3.6: Car Test 2 - GPS Path......................................................................... 53 Figure 3.7:Car Test 2 - Accelerations and Inclination.......................................... 54 Figure 3.8: Car Test 2 - Heading .......................................................................... 55 Figure 3.9: Car Test 2 - GPS Speed...................................................................... 56 Figure 3.10: Car Test 3 - GPS Path....................................................................... 57 Figure 3.11: Car Test 3 - Acceleration and Inclination ........................................ 58 Figure 3.12: Car Test 3 - Speed ............................................................................ 59 Figure 3.13: Car Test 3 - Heading ........................................................................ 60 Figure 3.14: Motor Current - unloaded................................................................. 61 Figure 3.15: Motor Current with Drive Train....................................................... 62 Figure 4.1: Motor Driver and Fan......................................................................... 64
vii
List of Tables Table 2.1: Conversion Times................................................................................ 36 Table 2.2: IIM7010A Settings .............................................................................. 41
viii
Acknowledgement I would like to acknowledge the following individuals and companies for their contributions to this project: Dr. Eric Thosteson for being my advisor and committee chair, for providing technical information and help troubleshooting problems. Dr. Andrew Zborowski for introducing me to the LOMAC project and providing insight and advice about the project. Dr. Hector Gutierrez for teaching me about the functions of the PIC microcontroller and providing insight and advice about the project. Dr. Stephen Wood for providing support for learning C18. Bill Battin for providing advice, options and construction help. Mark Cencer, Travis Burland, and Patrick Hatton for constructing the LOMAC. Eduardo Gonzales for continuing to work and improve the LOMAC, construction help, and testing help. Dr. Brian Howell for providing advice and sharing a work space and supplies. Florida Tech’s University Publications for use of the use of the campus map. Microchip, Texas Instruments, Maxim Semiconductor, Analog Devices for providing free samples of their products. Wiznet for creating the IIM7010A, making TCP/IP and Ethernet communications simple. Without these individuals and companies this project would never have been realized.
ix
Dedication
To my family who supported me.
x
1.0 Introduction With emerging technology, researchers desire to obtain their sensor data faster
and to make remotely acquired data available over longer distances. In the past,
the data needed to be logged on a data logger and downloaded later, or a computer
had to be directly connected to the sensor. For fast access to remote data, costly
proprietary radio modems were employed. This is changing with the prevalence
of the Internet, the trend making everything Internet-enabled, and the introduction
of wireless Ethernet with its drastic cost reductions.
1.1 Goals The goal of this thesis is to design, implement, and test a remote, wireless, nearly
real-time sensor and data acquisition system for evaluation of the performance
characteristics of a boat. To evaluate the performance characteristics of the boat
the acceleration in 3 axes the heading, the pitch, roll, speed, and location. This
microcontroller-based system design is modular, so it can be implemented in
other applications. The communications system will be based on the TCP/IP
communication protocol and will run on 802.11 and 802.3 Ethernet hardware.
The TCP/IP protocol was chosen because of its prevalence in the world today.
Ethernet was chosen as the hardware to use, since the introduction of 802.11
1
wireless Ethernet allows transmission of data over moderate distances quickly,
easily and inexpensively. The processor that will be used is from the PIC family
of microcontrollers made by Microchip, Inc. Firmware for the microcontrollers is
written in a combination of BASIC and C. In the following work, the combined
implementation of these technologies, termed the PICNIC system, is described.
1.2 Background The systems described are not new they draw from the previous works of others
and currently available technologies. The boat (LOMAC) that the data collection
system is to be implemented on was built as part of a Marine Field Project by
Burland et al. Wireless data acquisition is not a new idea researches have been
utilizing in different forms for years but never in the way presented here. TCP/IP
communications is a technology that the internet is based on. During the course of
this project two different languages where used to program the PIC
microcontrollers; Pic Basic Pro and PIC C18.
2
1.2.1 LOMAC
Figure 1.1: LOMAC Model Hull LOMAC (Littoral-Operation Multipurpose Auxiliary Craft) catamaran was
designed by Andrew Zborowski to provide optimal stability in the littoral zone
(Burland, et al. 2002). The craft was designed to operate in the harsh wave
conditions found in the littoral region. Burland et al. built and tested a model of
the catamaran (
Figure 1.1). Using the sensor and data acquisition system described herein, this
model is going to be used to analyze the expected performance of the prototype
vessel in the littoral region. Characteristics to be analyzed are the hull motions
and maneuverability in wave conditions expected in the littoral region. This thesis
3
describes the PICNIC, an innovative sensor, data acquisition, and communication
system which allows this data to be obtained in near real-time. Two 3-axis
accelerometers, two inclinometers, and a compass will provide data needed to
reconstruct the motions of the vessel. A GPS will provide location, speed and
rough heading. Data from these sensors is transmitted from the model to a remote
PC over a wireless TCP/IP network as seen in Figure 1.2.
Figure 1.2: System Block Diagram
4
1.2.2 Wireless Data Acquisition Wireless data acquisition is not a new idea, however the combination of
technology being used in the PICNIC system is new. In previous systems
described in the literature, PIC and other microcontrollers have been used for data
collection and wireless Ethernet has been used for data communication. Only
recently has the integration of the two technologies been made possible. Several
different configurations were found in a review of recent papers on wireless data
acquisition.
Hamel et al. (2002) used a PIC microcontroller and RF transmitters to collect
data. Their goal was to create a scalable network of sensors using TDMA (Time
Division Multiple Access) networking. In this application they have several
sensors that wake up and wait for random periods of time before transmitting a
packet of data to a SBC (single board computer). The SBC checks the integrity of
the communication, since more than one node can potentially transmit at the same
time. The integrity is checked by comparing the checksum in the packet with that
computed on the receiving end. If they don’t match, the system discards the
information. This system was designed for low speed acquisition. The example
presented had an acquisition interval of 5 minutes with 100 nodes and had a data
loss of 10% from rejected information. The data stored on the SBC can be
accessed via multiple techniques: over an Ethernet network, cell phone or a
5
conventional phone line. The data on the SBC is available in several formats,
including HTML, XML, or comma delimited text. The data needs to be offloaded
periodically, since upon filling the data storage space, the system will stop
logging and preserve the already collected data. The SBC has a storage capacity
of only 128 Kbytes. The system can transmit data in intervals as low as one
second and collect it at a rate of 200 Hz (Hamel, 2002).
In this system, it is likely that data loss would increase with shorter transmission
intervals due to a greater chance of collision from two transmissions occurring in
the same time frame. This is a potential problem since the system includes no
mechanism to recover lost data. Another limitation of this system is the small data
storage capacity, since new data is rejected after reaching capacity.
Adcock et al. (2001) use a microcontroller and an RF modem to transmit data
back to PC. Their system was designed to replace the traditional data acquisition
system used in a wind tunnel. The goals of this system were to reduce error and
noise in the system by removing alternate load paths and removing long sensor
leads. Traditionally the sensors in the test model were connected via long wires to
the data collection system. These wires provided alternate load paths inducing
error in the loading readings. The length of the wires needed to connect to
equipment outside the wind tunnel resulted in an increase in the amount of noise
6
introduced into the readings. Antenna placement is a concern, because some
models made of metal require an external antenna that won’t modify the
aerodynamics (Adcock, 2001).
This is a good example of how RF modems have been used with microcontrollers
to acquire data wirelessly. This is a good example of how wireless technology can
be used to improve existing data acquisition situations.
Lohachit et al. (2003) describe a system that uses a PC104 stack and a RF modem
to collect water quality data from a remotely controlled boat. The system collects
water quality, depth, compass heading and GPS data. This data is transmitted real
time back to a PC for logging. The boat is controlled by an R/C controller and has
proximity sensors to alert the operator of collision hazards. The PC/104 on the
boat runs Linux. A digital compass is used in the system to backup the GPS since
the GPS will only provide heading data while the boat is moving. This system can
be used to map the water quality and contour of a shallow water environment
(maximum depth of 3 feet and a minimum of 6 inches). The boat that caries the
system is 7 feet long and 3 feet wide and is powered by a 12 volt trawling motor
interfaced to an R/C controller. Their RF modem provides a 900 meter operating
range, but the boat is also limited by the operator’s line of site (Lohachit, 2003).
7
This is the closest example found in the literature to the PICNIC system in
application. It gathers data in a similar way; it collects data remotely and sends it
back to a PC to log it. This system is also mounted on a boat that is driven by an
R/C controller, like the LOMAC.
Mitchell, et al. describe a system consisting of a cluster of sensors that pass data
to a central cluster, which further communicates to an outside system using a
cellular modem. This system was designed to be a low cost system for use in
monitoring the “health” of a structure, like an airplane’s airframe. Requirements
for the sensors included the need to occupy a small amount of space and to use a
small amount of power. The sensors are based on Cygnal’s system on chip,
communicate using Bluetooth, and can pass data from each other to the central
cluster. According to the official Bluetooth membership site,
The Bluetooth wireless specification defines a low-power, low-cost technology that provides a standardized platform for eliminating cables between mobile devices and facilitating connections between products. … Radios that comply with the Bluetooth wireless specification operate in the unlicensed, 2.4 GHz radio spectrum ensuring communication compatibility worldwide. These radios use a spread spectrum, frequency hopping, full-duplex signal at up to 1600 hops/sec. The signal hops among 79 frequencies at 1 MHz intervals to give a high degree of interference immunity.”(Bluetooth.org, 2004)
The central cluster is a PC104 system running Windows. It uses Bluetooth for
communications with the sensors and a cellular modem for communications to a
8
PC. The PC functioned as a web server, so the data could be accessed via the
Internet. This was a culmination of several iterations of the system. During the
iterations they came up with error checking and communication protocols of their
own to facilitate the data transfer. Since the PC104 system has a hard drive it is
tolerant to a loss of the cellular connection. It can buffer the data during a
connection loss, reconnect and upload all the buffered data (Mitchell, 2002).
Mitchell et al. presented many different technologies that can be used in wireless
data acquisition but didn’t make use of Wireless Ethernet, possibly due to the low
power requirements of the final design. This system illustrates the complexity in
ensuring data integrity when developing a communication protocol.
Edward’s describes (1998) a system of two PC104 computers that are connected
back to a central monitoring system via a cellular modem. The system was
designed for analysis and monitoring potential failure of a design in field
conditions. One of the goals was to design a system that required no human
interaction. Another goal was to create a system that could withstand harsh
conditions. The communication system needed to be able to operate in a variety of
locations across the county. Several cellular and satellite options were explored
for feasibility, availability and cost. Analog cellular was chosen because of
geographical area covered and the low cost of implementation. Each of the PC104
9
systems had different functions. One was responsible for collecting the data and
the other for handling the communication with the central monitoring system. The
two PC104 computers were connected together using Ethernet networking. The
system had the ability to gather many types of data including GPS, digital vehicle
data, and analog values like strain. Data was transmitted back to the home base at
timed intervals, cellular connection permitting (Edward, 1998).
This system had a great number of applications and had the capacity to gather
large amounts of data. The system utilized cellular communications to give it a
large coverage area, which creates a more mobile system, but incurs monthly
service and air time charges. The system is a slightly over-powered and costly due
to the use of two PC104 systems. Much of the data collection could have been
handled by microcontrollers, as seen in other papers.
Raygan and Callahan (2004) review data acquisition capabilities of currently
available computing systems and 802.11b for wireless remote data acquisition.
They review the capabilities of various interface types, like USB, USB 2.0,
FireWire, IEEE 488, Ethernet, and PCMCIA. The paper recommends using Linux
as the operating system since it is open source and therefore low cost. Several
platforms for central processing are examined including the PC, a PDA (personal
digital assistant) and a SBC (single board computer). It was proposed that by
10
storing of the downloaded data in a database and using SQL (structured query
language), the data could be manipulated to produce the desired output. They
suggest that in order to preserve data integrity, raw data should not be altered and
the manipulated data should be stored in separate tables (Raygan, 2004).
While Raygan and Callahan present a good review of the capabilities of the
presented technology, it could have been more comprehensive, considering the
use of microcontrollers and operating systems other than Linux. The idea of using
a SQL database for management of the data was unique among the articles
reviewed.
In Winfield and Holland (2000), a group of robots are each controlled by the use
of an onboard 386SX CPU running Linux and communicate using a wireless
LAN. In this application, each system can be remotely monitored and modified by
use of a designed program. Each system is accessed by remotely logging-in via
Telnet to the Linux system running on the individual. Each robot is individually
accessible by its IP address. The paper compares TCP and UDP as protocols for
communications, and concludes that TCP is a better choice because of built-in
error control, preserving data integrity. It was observed that there was a latency of
3 to 6 ms between the external controller and the robots. For this reason, the low
11
level controls were handled onboard while higher level control operations could
be commanded from the external controller (Winfield, 2000).
The choice of the TCP protocol confirmed recommendations from other sources
The concept of multiple nodes accessed by IP could also be applied to a sensor
network.
Several previous endeavors using wireless technology for data acquisition have
been described. No instances were found which used 802.11 wireless Ethernet
technology with a microcontroller. RF modems were used when microcontrollers
were used. Instances where wireless Ethernet was implemented, PC-based
hardware was used. PC-based hardware also was connected using cellular and RF
modems. In the projects reviewed, the PC-based hardware had greater data
processing capabilities. The combination of a microcontroller and wireless
Ethernet technology is relatively new. This is likely due to the small amount of
data that is normally produced by a microcontroller - small compared to the
capacity of an 802.11 wireless network.
12
1.2.3 TCP/IP Communications Overview
According to Bentham, TCP/IP (Transmission Control Protocol/Internet
Protocol) communications is layered (Bentham, 2002). In this application,
Wiznet’s IIM7010A handles most layers of the stack, allowing the top layer,
application, to be the focus. When using TCP/IP on an Ethernet network, there are
several things that must transpire before the communication between the
machines may occur. In TCP/IP, network nodes are identified by IP addresses.
Communication is initiated between 2 nodes by a client node specifying the IP
addresses of the server node with which it wants to initiate communications.
Ethernet hardware doesn’t recognize these IP addresses. Ethernet was designed to
handle multiple protocols and has its own addressing scheme. These Ethernet
addresses are commonly know as MAC (Media Access Control) addresses, or
physical address. The MAC address is a 6-byte address that is unique to the
individual hardware component and is issued by IEEE to manufacturers. The
TCP/IP stack on one node sends out an ARP (Address Resolution Protocol)
packet. This packet is sent out to the network asking for the MAC address
corresponding to a particular IP address. Once the ARP returns with the correct
MAC, communications between the two nodes may begin.
13
In TCP/IP, communication ports are specific destination spots on the nodes; they
allow simultaneous use of several available services. The client and server both
must know from which port to expect the data. A great number of ports have been
standardized as the default ports for certain applications, i.e. Port 80 is used for
HTML requests. This means that by default, most web servers will be listening on
port 80 for HTML requests. If a web server is set up to listen on a non-standard
port, the web client must specifically request information from the proper server
port number.
TCP/IP communications can take two forms: UDP and TCP. UDP and TCP both
use an IP address and a port for communications. UDP is a simple way to transfer
data from one place to another using a small packet of data, but verification of
data receipt is included in this protocol. TCP communication is more complicated.
TCP communication includes data loss protection. It verifies that every packet of
information is received and resends unconfirmed packets. This makes TCP a more
reliable form of communication, but also requires greater overhead for
communications.
14
1.2.4 Pic Basic Pro and PIC C18 PIC microcontrollers are a FLASH based, allowing them to be programmed for
specific applications. PIC’s assembly language is not user friendly therefore
higher level languages were used in the development of the code for the PIC
microcontrollers used in this project. Two different languages, microEngineering
Labs’ Pic Basic Pro version 2.24a and Microchip’s PIC C18 version 2.30, were
used during the course of this project. Each language has advantages and
disadvantages.
Micro Engineering Lab’s Pic Basic Pro is a simple programming language. It
provides a great number of commands that can use the hardware peripherals of
the PIC, and additionally, it provides software based implementations of these
peripherals, extending the capabilities of the PIC. The use of these commands
provides many functions including I2C communication, USART communication,
standard LCD character display control, and Pulse Width Modulation, as well as
standard programming commands. Pic Basic Pro’s largest data element size is a
word (2 bytes) and it has no signed or floating point values. Pic Basic Pro is able
to handle arrays of data, but does not directly handle null terminated strings. The
greatest advantage of Pic Basic Pro is that it is not tied to a specific processor
family. It can be used with certain members of the 12 series, 16 series, 17 series,
and 18 series of PIC microcontrollers. Pic Basic Pro has two limitations when one
15
tries to create complex code. First, variables can not be passed to subroutines.
Second, it does not support the use of pointers. All memory allocation in Pic
Basic Pro is static. Interrupts in Pic Basic Pro are handled after the current
command finishes executing. This can be helpful, since interrupts are supported,
but can also cause latency problems depending on the execution time of the
command. Pic Basic Pro is ideal for the beginner programmer and good for
simple programs.
Microchip’s PIC C18 is an ANSI C based compiler. Unfortunately, it doesn’t
contain many of the standard libraries normally associated with a C compiler. The
main limitation of PIC C18 is that it will only work with the 18 series PICs. The
libraries that come with PIC C18 which support the PIC’s hardware peripherals
are limited in their functionality. The commands within these libraries only
manipulate registers, which is easily done without making use of the libraries. The
software based functions that mimicked hardware functionality of the PIC were
not used and therefore can not be evaluated. PIC C18 has three significant
advantages over Pic Basic Pro. First, variables can be passed to a subroutine.
Another advantage of PIC C18 is that it can dynamically allocate memory. This
complicates debugging, but it improves memory management. The same memory
locations can be reused by different functions. Finally, PIC C18 allows the use of
pointers. A pointer simplifies data manipulation, especially with larger data types.
16
PIC C18 supports a multitude of data types, ranging from signed or unsigned
characters, to double precision floating point numbers, to null terminated strings.
It has libraries for manipulation and creation of these strings. All of this
functionality makes PIC C18 an ideal compiler for complex program generation.
1.3 Scope Several systems were designed and implemented during the course of this
research for use with the LOMAC. The system has been implemented on several
stackable circuit boards using generic connections. Connections between boards
in the stack are made with an IDE cable that passes all of the relevant pins of the
PIC to the other boards. The cable also distributes power to most of the items on
the stack. The boards are the PICNIC board (communication), GPS/power board,
and accelerometer/sensors board. There is also a breakout breadboard which
provides the LCD screen connection and another PIC used to read the inclination
sensor. Motor drivers for the jet drive system in the LOMAC were also designed
and implemented. These motor drivers are controlled by an R/C interpreter board
that interprets an R/C receiver’s commands.
17
In the course of this research, these systems will be tested and evaluated. The data
produced by the PICNIC system will be presented in a discernable manner. The
power drawn by the motor controllers and engines will be analyzed.
18
2.0 Systems Within this research, there were several systems designed. There are two
categories of systems designed; the LOMAC drive systems and the sensor and
data acquisition / communication systems.
2.1 LOMAC Drive Systems
Figure 2.1: LOMAC Drive System Diagram
The drive system is composed of two parts; the motor driver and the R/C control
interpreter. The systems are controlled by a Futbar FP-R127DF FM receiver. The
initial design of the system assumed the boat could be steered by use of
19
differential powering - powering one engine more than the other. This assumption
would prove to be wrong.
2.1.1 LOMAC Motor Driver The LOMAC uses jet drives for propulsion Figure 2.2. This means that the motor
driver only needs to drive the motor in one direction since water jets operated in
reverse provide little propulsive force. The motor drivers were designed to use
PWM (Pulse With Modulation) to drive the motors, Hall Effect sensors to count
shaft rotations, and an onboard 555 timer as a time base. The motor drivers are
programmed in Pic Basic Pro and communicate with the R/C interpreter board
using I2C.
Figure 2.2: LOMAC Jet Drive System
20
I2C is an addressable two-wire synchronous serial communication protocol which
supports communication between multiple devices on the same bus. There are two
types of devices on the bus: the master and the slave devices. There can only be
one master on a bus, but there can be up to 128 slaves. Each slave device on the
bus has its own 7-bit address on the bus, also known as a control code. The slave
device only responds to commands incorporating its control code. Slave devices
can also have their own internal addressing schemes. From this point forward, all
bus addresses will be referred to as control codes and internal addresses will be
called addresses.
To use I2C communications, the motor driver board, Figure 2.3, was configured as
a slave device, as seen in the program listing in Appendix A: LOMAC Motor
Drive Code. The program for the slave communication checks both the I2C
control code and the address specified by the master. After receiving the control
code, the slave device receives the address of the variable from which the master
wishes to read or to which the master wishes to write. After the subsequent read
or write command, the slave device’s internal address is reset, expecting a new
address to be sent. This requires that the internal address be specified with each
access.
21
Figure 2.3: Motor Driver Board The specified motors require a nominal current of 12 amps at 12 volts. To provide
this power, a MOSFET was used to amplify the PWM signal from the PIC.
International Rectifier’s IRLBA3803 N – channel MOSFET was selected because
of its ability to function with continuous currents exceeding 100 amps and its
ability to handle 30 volts from drain to source. The current from the PIC is
insufficient to trigger this MOSFET at the desired frequency because of the high
gate capacitance of the MOSFET. MAXIM’s MAX4420 MOSFET driver takes
the logic signal from the PIC and provides sufficient current to drive the gate of
the MOSFET. The PWM signal the motor receives is now double buffered from
the PIC through the MOSFET and the MOSFET driver.
At present, the Hall Effect sensors are not installed, since pool-tests suggest that
the drive train of the LOMAC should be replaced. The Hall Effect sensors would
22
require a magnet to be attached to the drive shaft, with the Hall Effect sensor then
mounted adjacent to the magnet. The sensors can be installed after installation of
a new drive shaft. The connections for it are shown on the motor driver board
schematic (Appendix F: Motor Driver Schematic).
2.1.2 R/C Interpreter The motor driver boards are controlled by an R/C interpreter board (Appendix G).
The original idea was to steer the boat using differential power, changing the
relative power in one engine to create a turning moment acting on the ship,
eliminating the need for a rudder. The interpreter board receives two signals from
the receiver: intensity and a left/right differential, both signals being pulse length
modulated signals. The interpreter board currently uses a control algorithm
written in Pic Basic Pro, Listing 1, to convert the intensity to a PWM value. The
full version of the code used with the R/C interpreter is in Appendix B.
Listing 1: Control Algorithm
controlP = intensity received from the R/C receiver, range 108 -190 108 = minimum intensity 190 = maximum intensity controlD = differential received from the R/C receiver, range 108 – 190 108 = maximum left turn 190 = maximum right turn outdataL = power setting for left motor, range 0 – 255 0 = engine off 255 = engine fully on
23
outdataR = power setting for right motor, range 0 – 255 0 = engine off 255 = engine fully on setspeed is where the speed of the motors is sent to the individual motors. if controlP < 117 then
intensity = 0 outdataL = 0 outdataR = 0 goto setspeed
endif if controlP > 180 then
intensity = 255 goto checkdiff
endif intensity = (controlP - 117) * 4 checkdiff: if controlD < 149 then
outdataR = intensity if controlD < 103 then
outdataL = 0 goto setspeed
endif diff = (149 - controlD) * 5 if diff > intensity then
outdataL = 0 else
outdataL = intensity - diff endif goto setspeed
endif if controlD > 151 then
outdataL = intensity if controlD > 192 then
outdataR = 0 goto setspeed
endif diff = (controlD - 151) * 6
if diff > intensity then
outdataR = 0 else
outdataR = intensity - diff endif
24
goto setspeed
endif outdataR = intensity outdataL = intensity setspeed:
The program then checks the differential signal. If there is need for a differential
adjustment, then the controller slows down one motor by a bounded linear
algorithm. These values are then sent to the motors. The algorithm does not
process the intensity and differential if there is no change in their values; this
reduces processor overhead and unneeded communication. The present interpreter
board could be removed, and the motor drivers could be controlled by any I2C
master. This could be the PICNIC, allowing the motor drivers to be controlled by
a remote computer or other TCP/IP device. This is not within the scope of this
thesis.
25
2.2 Data Acquisition and Communication Systems
Figure 2.4: Data Acquisition and Communication System
The data acquisition and communications systems, Figure 2.4, were designed to
gather data from the LOMAC. The data acquired from sensors on the LOMAC
will be used to reconstruct the LOMAC’s motions. The system employs several
sensors: accelerometers on 3 axes, inclinometers on 2 axes, a digital compass, and
a GPS. In addition to these sensor readings, motor voltages and voltages from
motor current-sensing amplifiers are sampled. The communication is facilitated
by the use of the stand alone TCP/IP stack and Ethernet controller in the Wiznet
IIM7010A system. All of these systems are centrally controlled by the PICNIC
system which functions as the Central Processing Unit facilitating the movement
of the information.
26
These systems are spanned across multiple boards, Figure 2.5, to create the sensor
package. All of the boards are connected via a 40 pin IDE cable that pass power
and access to the pins of the PICNIC to the other board and provides for future
expandability. The bread board is the only non printed circuit board but is a
prototyping board used for integration of systems with out circuit boards. This
includes the Inclinometer PIC and the LCD screen.
Figure 2.5: Sensor System Board Diagram
27
2.2.1 GPS Reader
Figure 2.6: GPS Reader System Diagram This system, Figure 2.6, uses a PIC 18F452 to read one sentence from a GPS
(Rockwell, 1998), making that sentence available on-demand to another PIC via
the I2C bus. This is done because the GPS independently outputs several different
sentences every second. These sentences are each approximately 80 bytes long.
The GPS outputs them as asynchronous serial data at 4800 bps. The PIC reads the
appropriate sentence coming from the GPS and then internally moves it to a data
section available to another device via I2C.
The GPS reader is an I2C slave device. An I2C request is capable of generating an
interrupt on the system. When the GPS reader receives a read request, it transmits
28
the last complete RMC sentence. The GPS reader only stores the Recommended
Minimum Specific GPS/TRANSIT Data (RMC) sentence,
Figure 2.7 ($GPRMC tagged sentence (NMEA, 2004)).
•
$GPRM RMC = 1 = U2 = D3 = La4 = N5 = Lo6 = E 7 = Sp8 = Tr9 = U10 = M11 = E12 = C
Appendix
appropriate
transmissio
received fr
transmittin
the I2C mo
data in the
read upon
RMC
C,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,ddmmyy,x.x,a*hh
Recommended Minimum Specific GPS/TRANSIT Data
TC of position fix ata status (V=navigation receiver warning) titude of fix
or S ngitude of fix or W eed over ground in knots ack made good in degrees True
T date agnetic variation degrees (Easterly var. subtracts from true course) or W hecksum
Figure 2.7: RMC NMEA Tag Definition (NMEA, 2004)
C contains the code that reads the serial GPS sentences, moves the
sentence to the outgoing string buffer, and handles the I2C slave
n. The string is long enough that it is likely that a serial byte or bytes
om the GPS will be in the incoming buffer while the I2C slave is
g the outgoing string. To avoid data loss, after each byte is loaded into
dule for transmission, the program checks the serial buffer. If there is
buffer, it is moved to a second buffer from which serial data can be
completion of the I2C transmission. After a sentence is completely
29
received, it is copied to the outgoing string buffer, and the program begins
looking for the next GPS sentence. This setup makes the GPS data available to the
system on demand and speeds up the transfer from 4.8 kbps to between 100 and
1,000 kbps.
2.2.2 Inclinometer System
Figure 2.8: Inclinometer System Diagram This system, Figure 2.8, is similar to the GPS system in that they both use a PIC
18F452 and are I2C slaves. The inclinometer, T2 3600 (US Digital, 2004), by US
Digital is an optical encoder that has a weight on it and is magnetically dampened
to minimize oscillation. Upon a change in inclination, the optical encoder outputs
30
signals on two channels together to generate a quadrature signal. This quadrature
signal consists of two square waves that are 90º out of phase with respect to each
other. The direction of the phase shift is related to the direction of rotation, i.e., if
channel A is +90º out of phase with channel B, then the rotation is clockwise.
This signal can be seen in Figure 2.9. Each channel’s signal is generated from the
output of a photo sensor, stimulated from an LED. Between the photo sensor and
LED is a transparent, rotating disk with evenly spaced markings that block light
from the LED. Each period represents the passage of one mark on the encoder
disk.
2 Increments Clockwise 2 Increments Counterclockwise
Figure 2.9: Quadrature Signal This quadrature signal is decoded by the PIC. This is accomplished by connecting
channel A to port B bit 4 on the PIC and channel B to port B bit 5. Bits 4 and 5
can be set to generate an interrupt on change. On this interrupt, the PIC checks the
state of both pins. The current state of the pins and the previous state of the pins
are used with a table to determine whether to add or subtract from the inclination
Channel A Channel A
Channel BChannel B
31
value, as seen in the source code in Appendix D. The counter is stored in a signed
integer (2 bytes). This value can be accessed by another device via I2C. Unlike the
GPS system, which recognized a data request by the generation of an interrupt,
the I2C slave code uses polling. The program checks to see if an I2C address
match has occurred, and when a match occurs, the inclinometer transmits its
inclination counter value.
The system has no built-in reference, therefore, the system is referenced to the
initial inclination from when the program starts. The counter is zeroed every time
the program starts, and the counter is modified by the signal from the
inclinometer. The encoder disk in the inclinometer has 900 marks on it. Moving
between marks moves the system through 4 binary states: 11, 10, 00, 01. The next
state starts the process over again at 11. This will generate 4 interrupts and 4
increments of the counter per cycle, giving the system a resolution of 0.1º.
The inclinometer system allows for the quadrature decoding based on interrupts.
Unfortunately, at this time only one inclinometer was available. Another
inclinometer should be implemented using the same system with a different I2C
slave address. This would allow measurement of the inclination along a second
axis.
32
2.2.3 Digital Compass
Figure 2.10: Digital Compass System Diagram The digital compass system, Figure 2.10, is based on Honeywell’s HMC 1052
(Honeywell, 2003). The digital compass outputs its heading via two analog values
that represent the X and Y components of the vector to magnetic North. With the
use of geometry, these values can be used to find the heading, as shown in Figure
2.11. Unfortunately, PIC C18 does not support trigonometric functions at this
time (but will in the future), therefore, the magnitudes of the North/South
component and East/West component are transmitted instead. The heading can
therefore be resolved by post-processing. The analog signals produced by the
33
digital compass are sampled by the PICNIC board. The digital compass board is
connected to the system’s accelerometer board, described next.
Figure 2.11: Heading Geometry
2.2.4 Accelerometers Two accelerometers were evaluated for use in this system, ADXL202E (Analog
Devices, 2000) and ADXL311 (Analog Devices, 2003), both made by Analog
Devices. The main difference between the ADXL202E and ADXL311 is the
available output generated by each. They are both ± 2G accelerometers and
operate at voltages from 3V to 5.25V. The ADXL311 outputs the acceleration as
an analog voltage. The ADXL202E outputs the acceleration as an analog voltage,
like the ADXL311, but also produces a digital output. When the voltage is being
used to measure the acceleration at 5V, 0 G is at 2.5V and 1 G is 0.312V offset
from that. In digital output the acceleration is found from a PWM signal. A 50%
34
duty cycle would represent 0 G. A 12.5% (1/8) change in the duty cycle
corresponds to a 1 G acceleration.
One thing to consider about these two outputs is the amount of time required to
acquire each. Using the digital output, the amount of time it takes is based on the
period of the PWM wave. The time for the acquisition by this method can take
just over one period and up to two periods. If the command to acquire the
acceleration is called just after a high pulse starts, then the processor must wait for
the next high pulse to start, resulting in a total sampling time of nearly 2 periods.
This means that at the shortest setting for the period, the acquisition can take as
much as 1 ms or as little as just over 0.5 ms. The shorter the period, the lower the
measurement resolution and the more significant the effect of the error induced
from polling. This does not seem like much, but the project design includes three
accelerometers and other devices as well, so the latency accumulates. To obtain
the optimal resolution, the accelerometer must be set to use a frequency of 350 Hz
for the PWM signal, yielding a possible maximum acquisition time of 5.7 ms.
The time it takes to acquire the acceleration using the analog method is
significantly different. The PIC’s minimum analog to digital conversion clock at
40 MHz is 1/64 the oscillator, which translates into 1.6µs per TAD (a TAD is the
time it takes for one bit to be converted). It takes 11 TADs to convert a 10-bit
35
value, or 17.6µs. As stated previously, the design needs to read 3 accelerometers.
This means that the A/D (Analog to Digital) module will need to switch between
analog channels. When switching channels, there is a required amount of time the
A/D module needs to be on that channel before a conversion can start. This time
varies with temperature, but following an example from the datasheet, for 50°C, a
12.86 µs delay is needed. With the required time for channel changing, the total
conversion time is 30.5µs.
Table 2.1: Conversion Times
0.000 000 025 s 0.025 µs Oscillator 0.000 001 600 s 1.60 µs TAD time
0.000 017 600 s 17.6 µs 10-bit A/D conversion time
0.000 036 800 s 30.5 µs
10-bit A/D conversion with delay for channel changing
0.001 000 000 s 1000 µs Max time for shortest period digital acquisition
0.005 700 000 s 5700 µs Max time for optimal resolution digital acquisition
Comparing the acquisition time between digital and analog, it can be seen that the
shortest digital acquisition time is more than 30 times longer than the analog
acquisition time than. In the amount of time required for one digital reading with
the optimal period, over 180 analog readings could have been made. In the initial
design stages there was a target of 100 samples per second. This criteria lead to
the selection of analog acquisition.
36
To use the analog outputs of the accelerometer, the voltage output is amplified to
provide better resolution. To amplify the signal, an instrumentation amplifier
design from the data sheet for Microchip’s op amp, MCP604 (Figure 2.12).
Figure 2.12: Microchip Instrumentation Amplifier (Microchip, 2004)
On the accelerometer board, each acceleration channel uses an instrumentation
amplifier. The V2 of each amplifier block was connected to an adjustable
precision 2.5V voltage shunt. The VREF of all the amplifiers were connected to the
same precision 2.5V voltage reference. This was done so that the amplification
would occur around the 0 G value of half the input voltage, equal to
approximately 2.5 volts. The adjustable voltage shunt allows for correction of an
37
offset that the sensor may have. In the circuit R2, R3, and R4 are 10kΩ ±1%
resistors, resulting in the equation 2.1.
VOUT = (V1 – 2.5V)(1 + (2* 10kΩ)/ RG)(10kΩ/10kΩ) + 2.5V E.Q. 2.1
The goal of the amplifier was to make 1 volt equal 1 G; this required a gain of 3.2.
An RG of 9.06 kΩ is needed to achieve this gain; an 8.55kΩ ±1% resistor in series
with a 1kΩ potentiometer was used to achieve this value.
Onboard, each accelerometer channel has two adjustments. Each channel has an
adjustment to regulate the center and the gain of the channel. This allows
calibration of the accelerometer system. The four channels of the acceleration are
Y, Z, X and Z again. The Z axis is measured twice because two vertically
mounted 2-axis accelerometers are used with duplication of one axis. Low pass
filters were added after the board construction to reduce high frequency noise.
These filters are not set to an optimal cutoff frequency, but they still greatly
reduce the noise in the accelerometers.
The accelerometers are read by the PICNIC directly using the analog inputs. The
PIC used by PICNIC has a 10-bit A/D converter. This gives 1024 steps of
resolution. In this application, the references are ground and the PIC supply
voltage, which is approximately 5 volts. An A/D conversion result of 0 would be
38
0 volts and 1023 would correspond to the input value. This can be problematic
since there is noise in the supply voltage. The accelerometers need to be
calibrated, but additionally the voltage of the system should be checked. It should
be close to 5 volts.
2.2.5 IIM7010A The Wiznet iinChip (Wiznet, 2002) allows easy use of TCP/IP communication by
handling the added overhead of this protocol. The iinChip handles pings, ARPs,
and packet formatting. The iinChip module being used is the Wiznet iinChip
IIM7010A. The IIM7010A integrates the iinChip W3100A (Appendix 2) and an
Ethernet controller. The IIM7010 is accessed from a Microchip PIC
microcontroller via the I2C bus. The iinChip is instructed by the microcontroller
to establish a connection or to wait for a connection on a certain port. The status
of the connection is then polled. After a connection is established, data is sent and
received freely. The iinChip buffers all communication data in two 8k byte buffer
for one transmission and another for reception. Incoming data is automatically
buffered and outgoing data is placed in the buffer prior to being sent. The device
uses a 4-byte pointer, though it uses only 2-bytes of this for addressing. The extra
bits in the pointer are used by the device to store information about the packet in
which the data was received or sent. Communication consists of checking the
39
status of the device, placing or reading information to or from the buffers, and
telling the device that reading or writing is complete in order to free allocated
buffer space.
The device has four channels, with a status register for each channel. For this
application, only one channel is used. The extra channels allow additional
simultaneous connections to the device. The status register shows whether
information has been received and the status of the connection (open, closed or
listening). There is also a register for device commands and additional status
information, such as the following: initialize the device, initialize the channel,
send data in buffer, and finished reading data in buffer.
The device is initialized by providing it with the network parameters. This
includes the IP address, gateway address, subnet mask, and the MAC address for
the device. When initializing a channel, the communication parameters are
specified. This includes the type of communication (TCP or UDP), the port on
which to communicate, and whether to wait for a connection or to initiate one.
This method of communication makes it viable for a PIC microcontroller to
communicate over a TCP/IP network.
40
2.2.6 PICNIC The PICNIC is the communications system that gets the data from all the sensor
systems. The PICNIC gathers the sensor data by use of the analog channels or the
I2C bus. The PICNIC also controls the IIM7010A via the I2C bus, controlling the
TCP/IP functions. In this case the PICNIC is the I2C master.
When the PICNIC is started, it first initializes the IIM7010A and then prepares a
socket. The IIM7010A is initialized with the parameters in Table 2.2. Next, socket
0 is prepared to listen on port 23, which is the standard port for Telnet, using TCP
communications. The IIM7010A waits for another device to connect to it on port
23 and then negotiates a connection.
Table 2.2: IIM7010A Settings
Gateway Address 192.168.1.1
Subnet Mask 255.255.255.0
MAC Address 00-A0-24-BB-D8-6A
IP Address 192.168.1.50
Initial Retry Time 100ms
Retry Count 255
RX Memory Allocation 8 kb to Ch 0
TX Memory Allocation 8 kb to Ch 0
41
While waiting for a connection, the PICNIC reads the analog inputs and the
inclinometer. It then displays the values on an LCD screen. The main purpose of
this is for calibration of the accelerometers, but this function is also useful for
providing debugging information.
When the PICNIC reads an accelerometer, it reads it 16 times and averages the
results. The averaging helps reduce noise by combining multiple data points,
reducing error generated by noise. It then converts the value to acceleration by
subtracting the equivalent of 2.5 volts from the averaged sensor reading,
multiplying it by 1000, and dividing it by the equivalent of 1 volt. This gives a
value that has 3 decimal places using fixed point notation. This value is then
converted into an ASCII string for either transmission or display.
When the PICNIC reads the digital compass, it reads it 16 times and averages the
readings like those from the accelerometers. The averaging is used to reduce error
from noise. The values are also centered based on an internal calibration value.
These values are then converted to ASCII and are combined into a null terminated
string with the values separated by a space. These values will be post-processed to
determine the heading.
42
Along with the digital compass reading, an optional analog channel is read. This
channel can read any voltage value that is within the range of the A/D converter:
0 to 5 volts relative to the ground of the system. This reading is also converted to
an ASCII value and appended to the null terminated string that contains the digital
compass readings. This was included for future expansion, as well as to input the
voltage across a current-sensing resistor. The string created from the digital
compass and the optional analog channel can be either displayed on the LCD
screen or transmitted back to the client.
After the PICNIC has finished displaying the analog channels and the
inclinometer on the LCD, it delays for 0.2 seconds, so the data can be seen by the
operator. It then sends the command to clear the screen and waits for 0.06 seconds
for the screen to finish clearing. The PICNIC then checks the status of socket 0 on
the IIM7010a. If the status reflects that a connection has been established, then
the program enters the data transmission routine. Otherwise, it repeats the cycle,
going back to check the analog channels and inclinometer and refreshing the LCD
screen.
If the connection has been established, the PICNIC moves into data transmission
mode. The data that is transmitted is based on the number of loops of the data
transmission code. The first time it loops through, it transmits the GPS
43
information. Every time the GPS information is transmitted, the loop counter is
reset. The GPS information is retransmitted after 250 loops of the code. The
accelerations, digital compass data, the optional analog channel, and the
inclinometer are output every five loops. Each GPS sentence is transmitted
approximately once per second. This means the acquisition rate for the rest of the
data is approximately 50 times per second.
At the end of each loop the program checks to see if the connection is still active.
If the connection has been lost, the program breaks from the loop and reinitializes
the socket. The program functions in several states: device initialization, socket
initialization, waiting for connection, and connected.
The PICNIC is capable of receiving data from the client, but it has been disabled
since it is unnecessary in this application. Functions supporting reception of data
are included in the code, since these were used in the initial development of the
communications program. Future applications may use this function.
The amount of data that can be transmitted is dependent upon the data rate and the
network reliability. If data is being generated faster than the data can be
successfully transmitted, then data loss can result. Successful transmission
requires the transmitted data to be acknowledged by the receiver. If the data that
44
is being transmitted is not acknowledged, the newly acquired data can overrun the
unacknowledged data. This will result in a loss of the older data.
45
3.0 Testing and Results During the course of this project several tests have been conducted. Some tests
were conducted in conjunction with the LOMAC and others were conducted
independently. The independent tests were conducted in a car. In the car, there
were two tests: a low speed test, at speeds similar to what the LOMAC should
achieve, and a high speed test, used to evaluate the system with readings of higher
magnitude.
3.1 Fall 2003 Pool Test In the fall of 2003, the LOMAC was tested in the South Gate pool on the campus
of Florida Institute of Technology. The purpose of this test was to test the motor
drivers, the R/C interpreter, and the integrity of the LOMAC hull.
When running the LOMAC in the pool, it was observed that the boat did not reach
the desired speed. The maximum speed the LOMAC could achieve was well
below the design speed. During the test, the operator tried to control the boat
using the differential steering but could not generate an effective turning moment.
The boat would turn slightly but not enough to effectively control the boat. While
running the boat at full speed, one of the MOSFETs on a motor driver board
failed and would need to be replaced at a later date.
46
It was also observed that leaks in the power transmission caused the boat to take
on a significant amount of water in the jet compartment. Over time, some of this
water seeped through the bulkhead into the engine compartment but not until
there were a couple of inches of water in the jet compartment.
3.2 Spring 2004 Pool Test This test was conducted after Eduardo Gonzales had reconditioned the hull,
constructed new water resistant housings for the motor control circuitry, and
resealed the bulkheads. One of the purposes of this test was to record data using
the PICNIC and sensor suite. Another purpose was to familiarize Eduardo with
the current performance characteristic of the LOMAC. At the time of this test, the
accelerometers’ outputs were not filtered.
At first, the LOMAC did not perform as well as it had in the previous tests. In the
initial test, the LOMAC could not move at all. After the initial trial the impeller
compartment was opened and it was found that the impellers were not turning
with the shafts. This was corrected and a second trial was attempted. In the second
trial, LOMAC performed as it had in the fall trial. The LOMAC still could not
47
achieve a speed that would be adequate for the scale model, but no additional
component failures occurred during these trials.
The digital compass and the inclinometer were not functioning during the test. It
was also seen that even though the GPS acquired a signal, there was no change in
the position during the test. The only data obtained was the acceleration data seen
in Figure 3.1 (landscape version in Appendix L).
Figure 3.1: Boat Test - Acceleration Data
48
There is a large amount of noise in the data. There appears to be an approximate
0.3 G noise band. The gap in the plot is a section where there was a buffer
overrun in the communications. There was only a small amount lost, but to ensure
signal integrity, the data was truncated to known good points based on GPS
sentences.
3.3 Car Test 1
Figure 3.2: Car Test Vehicle This test’s purpose was to simulate the model-scale speeds the LOMAC was
designed to achieve. In this test the PICNIC and sensor suite were secured into the
rear passenger seat in a Honda CRV, Figure 3.2. The GPS antenna was removed
from the sensor box so that it could be placed on the dashboard in order to receive
49
a signal. Since the last test, the accelerometers had been fitted with low-pass
filters to reduce noise. The digital compass and the inclinometer were both
reworked since the last test.
In the post-processing, it was found that the digital compass still did not function
correctly. It was also found that the GPS did not start correctly. It is a known
problem that the GPS occasionally does not initialize properly when the unit is
turned on. At present, the only way to correct this is to reset the main power.
Figure 3.3: Florida Tech Campus (Florida Institute of Technology, 2004) The test course was a single lap around the residents’ parking lot across from
Roberts Hall, on the campus of Florida Institute of Technology in Melbourne,
Florida (Figure 3.3, Appendix K). There were no noticeable inclines on the test
50
course. Despite the aforementioned problems, the system recorded the
accelerations and the inclinometer. Figure 3.4 (landscape version in Appendix M)
shows the four accelerometer outputs. Inspection of the inclination data revealed a
trend which is best understood when overlaid with the acceleration data, as seen
in Figure 3.5 (landscape version in Appendix N).
Figure 3.4: Car Test 1 – Acceleration
51
Figure 3.5: Car Test 1 - Acceleration and Inclinometer
As in the previous test, there is a small gap in the data do to a communications
buffer overrun. The data was again truncated to include only data known to be
good based on GPS sentences. Also, like the previous test, there was some noise
in the acceleration measurements, but it was greatly reduced to approximately a
0.04 G noise band.
3.4 Car Test 2 In the next car test, the devices that were not working were fixed. Like the first
car test, this one took place in the resident’s parking lot and was conducted at
52
speeds similar to those the LOMAC should achieve. This test consisted of two
laps of the parking lot. Figure 3.6 shows the logged GPS locations. During this
test, all of the sensors functioned.
Figure 3.6: Car Test 2 - GPS Path.
The accelerations and the inclination recorded during this test are shown in Figure
3.7 (landscape version in Appendix O).
53
Figure 3.7:Car Test 2 - Accelerations and Inclination The heading was recorded by both the GPS and the digital compass. The GPS
only records the heading when there is a change in position and the recorded
heading is based on that change. If there is no motion, the GPS heading is
recorded as 0 degrees. The offset values for the digital compass were calculated
based on ranges of values recorded. The compass provides a North/South
component and an East/West Component. The center value, or offset, of each of
these components is subtracted from the recorded value, and the resulting quantity
is scaled such that both components have the same range. Then, the ATAN2
function is used to find the heading. The heading according to the GPS and the
digital compass for Car Test 2 are shown in Figure 3.8.
54
Figure 3.8: Car Test 2 - Heading
The speed according to the GPS was also recorded and is shown in Figure 3.9.
55
Figure 3.9: Car Test 2 - GPS Speed
3.5 Car Test 3 Car Test 3 was conducted under normal city driving conditions to see how the
system responded under higher speeds. The test was conducted between the
parking lot on Country Club Road and the Sugar Mill Apartment complex, in
Melbourne, Florida. This path can be seen in the GPS track in Figure 3.10.
56
Figure 3.10: Car Test 3 - GPS Path
The acceleration and the inclination during this test are shown in Figure 3.11
(landscape version in Appendix P). During the test, three speed bumps were
encountered between times 175 second to 210 seconds.
57
Figure 3.11: Car Test 3 - Acceleration and Inclination As in the previous test, the speed was recorded by the GPS. It can be seen in
Figure 3.12 that the maximum speed in this test was 26 knots almost twice that
from the previous test.
58
Figure 3.12: Car Test 3 - Speed
The heading according to the digital compass was processed in the same manner
as the previous test, which revealed a problem with that method. It requires the
sensor package to travel a full 360° degrees in the course of the test to be properly
calibrated using the present method. During the course of this test, the sensor
package did not travel a full 360°. The problem is obvious in Figure 3.13, which
shows the heading according to the GPS and the digital compass.
59
Figure 3.13: Car Test 3 - Heading
3.6 Engine Power Test Determining the power used by the engines was an important element in the
development. After the first failure of the MOSFETs in the pool tests, there was a
desire to know the current drawn by the motors. The current supplied to the motor
was found by using current sense resistors and a current sense amplifier. Two
0.005Ω resistors in parallel, yielding a 0.0025Ω resistance, were placed in series
with the motor on the higher voltage side of the motor. The voltage was measured
across the resistance using a current sense amplifier with a gain of 100. The
60
current sense amplifier outputs 100 times the voltage sensed across the resistors.
Knowing the voltage across a known resistance provides a measure of the current,
by use of equation 3.1.
I = V/R EQ 3.1
In the lab, the current was measured under two conditions. In the first condition,
the motor was not connected to anything, so it was essentially unloaded with only
internal frictional resistance. Figure 3.14 shows the current during the unloaded
test.
Figure 3.14: Motor Current - unloaded
61
In the second condition, the engine was attached to the jet drive system. Figure
3.15 shows the current running through the motor while attached to the jet drive
train, but running in air.
Figure 3.15: Motor Current with Drive Train
62
4.0 Discussion There were a number of tests and types of tests used in the evaluation of the
system. These tests provided a great amount of information about the design and
resulted in several modifications of the systems.
The fall and spring pool tests showed that the boat was greatly under-powered.
They also showed that with the present powering, the differential steering would
not work. This is because the jet drive propulsion system was not providing
enough thrust and could not generate enough moment to turn the ship in the
desired space. If the propulsion system provided greater thrust, it is possible that
the boat could be controlled using differential steering. Since the propulsion
system needs to be altered, however, the timing and synchronization systems were
tabled until a viable propulsion system could be installed. The motor driver
boards are equipped to receive data from a Hall Effect sensor to determine the rate
of revolution of the motor shaft when a new propulsion system is installed.
The failure of a MOSFET during the fall 2003 pool test was determined to be a
result of overheating. This problem was addressed by adding a small brushless
DC fan into the new water resistant boxes that house the motor driver and battery.
This fan blows directly over the heat sink attached to the MOSFET (Figure 4.1),
63
removing excess heat. During the spring 2004 pool test, the new water resistant
housings with the fans were used. During this test, there was no damage to the
MOSFETs; the fans provided the needed cooling.
MOSFET
Fan
Figure 4.1: Motor Driver and Fan
During the spring 2004 pool test, the PICNIC communication system was used.
There were several problems found in this test. Looking at the data collected, the
GPS worked but did not pick up any change in position. This is likely due to the
small distance covered. This is the most likely reason as the GPS time kept
changing, but none of the base data changed. If the GPS device had stopped
transmitting, then the result would have been the same GPS data repeated with no
time change.
After examining the acceleration data captured from the spring 2004 pool test, it
was seen that the analog inputs needed to be filtered. There was a large noise
band, making it difficult to distinguish the small changes in the acceleration that
64
are needed to determine motion. After the testing, a low pass filter was added to
each of the accelerometer channels to reduce the noise and to try to prevent
aliasing. The cut off frequency of the added filter is too high, but it is the best that
could be added at the time without major modification of the circuit board.
Comparing the results from the first car test to results from earlier pool tests, the
filter greatly reduced the noise but did not eliminate it.
During the first car test neither the GPS nor the digital compass were operating
properly. The GPS had not initialized correctly. In the investigation of the failure
of the digital compass, it was found that one of the analog channels from the
digital compass was not connected to the analog channel of the PIC. This was
corrected, but the range of output was less than optimal. To fix this, the gain of
each of the amplifiers on the board was increased. At first, the range was
increased, but over time the range decreased again. The original design for the
integration of the digital compass left the magnetic set and reset straps on the
compass unused, since the author was led to believe they were unnecessary for a
low accuracy compass. The following approach was taken since there was a
mistake in the digital compass circuit design. Based on a recommendation from a
Honeywell Application Note, the circuit used a DC-DC converter to step up the
voltage applied to the set/reset strap on the compass. The inductive DC-DC
converter both induced excessive noise in the circuit and reduced the battery life.
65
This high voltage was used in the compass set/reset circuitry to generate a high
current to realign the magnetic field around the magneto-resistive sensor. The
current required to realign the magnetic field in a compass application is
significantly less than that which was being applied. The current needed to realign
the magnetic field could be achieved using the existing 5-volt supply. Through
experimentation, it was found that triggering the set and reset pins on the digital
compass board reset the range. Unfortunately the only way to presently trigger the
pins without redesigning the compass board is to temporarily connect these pins
to the 5-volt supply. The increased range increases the resolution of the compass.
With the reduced range, it still produces a 360° response when moved in a
complete circle, but the accuracy of the reading is greatly reduced.
From the acceleration and inclination data collected during all of the car tests, it
can be seen that the inclination follows the x-axis acceleration even though there
was minimal change in angle. This is due to the way in which the inclination is
measured. It is measured using a hanging weight which aligns with the total
acceleration vector acting on it, which is gravity in the static case. Additional
accelerations resulting from the motion of the system contribute to the total
acceleration vector, and also act upon the weight in the inclinometer. This can be
factored out, but will be difficult since it would require the inclination to be
66
corrected based on the measured acceleration. The corrected inclination would
then be used to properly orient the measured components of acceleration.
From the data collected in the pool tests and the car tests, it can be seen that there
are gaps in the measurement time series. These gaps result from buffer overflows.
In the case of a buffer overflow, the data loses its uniformity. In processing, when
a buffer overflow occurred, the associated data collected was discarded. What
remained were points that were justifiably good based on the GPS sentences, and
the time loss was estimated from the GPS time. This is less than ideal. Buffer
overflows occur when a lot of the transmitted information is not acknowledged.
When transmitted data is acknowledged the buffer space it occupies is released. If
the data being put into the buffer exceeds the free space, it overwrites the oldest
information in the buffer. Data is not acknowledged for many possible reasons,
including network collisions and wireless signal interference.
After examining the raw data from the car tests, it was seen that the timing
scheme used in the data collection was flawed. The scheme used during those
tests was based on the code execution time, which was assumed to be evenly
spaced. The GPS sentence was read approximately every second. This was not the
case. The GPS sentences were repeated in some cases and sentences were missed
in others. It was seen that the spacing of the GPS data was not consistently one
67
second. Because of the sensitivity to time in determining position from
accelerations, the resulting error would be excessive. The timing scheme was
changed, tying the timing to the processor clock. In this configuration, an
interrupt is generated every millisecond, adding one to a counter. This internal
time base is output with the sensor data each time, giving each sensor reading a
time stamp. Initially the system was set to read the sensors 40 times a second and
the GPS once per second based on the timer count. According to the time stamp,
in the original configuration, the first of the sensor readings was lost. It was then
decided to reduce the sensor reading to 25 times per second. At this rate the first
sensor reading was not lost. Also, at this rate, the chance of a buffer overflow is
reduced, since there is only about half the data being transmitted in the same
amount of time.
In car tests 2 and 3 the heading measured by the digital compass and GPS was
captured. From the headings in Figure 3.8 from car test 2, it can bee seen that the
digital compass and the GPS agree well. In this case, the digital compass is likely
more accurate because of the way in which the GPS heading is found. The
heading from the GPS is determined based on the movement. The resolution of
the motion is limited by the ability of the GPS device to sense a change in
position. Looking at the heading in Figure 3.13 from car test 3, it can be seen
there is a disparity in the heading from the digital compass and the GPS. In this
68
case, the GPS is more accurate. The disparity occurs because of the calibration
method used for the digital compass. For the calibration method to work, the
sensor package must be rotated 360°, producing readings over the whole
measurement span. From car test 3’s GPS path, Figure 3.10, it can be seen that the
car never faced in the west direction. This resulted in a faulty calibration of the
digital compass, offsetting the headings. This could be corrected based on the
GPS results, but it would be better in the future to make sure a good calibration
turn occurs during the test, such that the sensor orientation spans from 0° to 360°.
Proper use of the set and reset functions of the digital compass should allow the
digital compass to be calibrated once instead of with every use.
Looking at the car test accelerations, it can be seen that with use of moving
averages, a good measure of the acceleration is achieved. The moving average
partially compensates for the remaining noise in the system. The x and y
components of acceleration recorded when the system was still (speed = 0 by
GPS) were flat lines. In these cases, the acceleration does not read zero, because
the accelerometers were not tuned on that day. This error is static and can be
factored out. In the z axis accelerations, the noise-like patterns are likely due to
vibrations in the car. From the record of z-axis accelerations from car test 3, it is
obvious where the car went over the three speed bumps in the parking lot; these
are the short large spikes.
69
The test of the engines on the LOMAC had two purposes; first to develop the
current sensor and second to see the new drain of the motors in the air. The sensor
that was developed will be used again later to measure the current drawn by the
motors in water trials. Looking at the results in Figure 3.14 and Figure 3.15, the
maximum current for the motor with no external resistance was about 2.25 amps
and with the resistance of jet drive was about 2.9 amps. These values agree with
idle current drain specified for the motor.
70
5.0 Conclusions and Recommendations The systems designed here represent new configurations of recent technologies.
The PICNIC system can be used in a wide range of other applications for remote
data acquisition over a network. Each of the sensor systems could be applied to
different applications. The current measuring system and the motor control were
designed to be used at a later time in the LOMAC project.
The system designed here is a network of other systems working in conjunction
with each other. The GPS reader system provides positioning data, speed data,
and heading data (while moving) on demand over the I2C bus. The inclinometer
system provides the current inclination in an axis on demand over the I2C bus.
The accelerometers provide 3 axes of acceleration in an analog format. The digital
compass provides the heading to magnetic north in an analog format. The current
sense resistor can measure high currents and output an analog equivalent to it. The
PICNIC gathers all of the data provided by these sensors and converts it into an
ASCII formagt and then sends it to the IIM7010A. The IIM7010A then uses
TCP/IP communication and Ethernet to transmit them to a Telnet client. The
Ethernet is converter to Wireless Ethernet for wireless communications.
71
The most unique system, and also the most refined system designed here, is the
PICNIC communications system. The system works well in this application, but it
also has the potential for so many other applications. In this application, only one-
way communication occurs, but the system is also capable of two-way
communications. The system works well in the one-way streaming of
information. There is the occasional buffer overflow, but the chance of an
overflow is decreased by reducing the amount of data transmitted per second.
The analog systems, including the accelerometers, digital compass, and current
sensor, worked well in the present system. The systems work adequately as
currently configured, but could be redesigned based on some of the lessons
learned. The analog channels should use an anti-aliasing low pass filter suitable
for the data acquisition rate. This would remove high frequency noise and prevent
aliasing. The analog channels could also use impedance matching circuitry to
minimize capacitive coupling while maintaining better signal integrity. Another
modification that could be made is for the set and reset connections of the digital
compass to be connected to the PIC and utilized. These modifications could be
done by redesigning the accelerometer board.
The use of the inclinometer can provide the inclination in an acceleration-free
environment. In this system, the inclinometer is based on gravitational
72
acceleration. The gravitational acceleration vector is tracked by a mass. The
acceleration the system experiences also acts on this mass. This makes the
analysis based on this inclination reading difficult to decipher. Using an external
reference not based on gravitational acceleration would provide a simpler motion
analysis. An external reference to consider is the orientation of the magnetic north
vector. By adding a third axis to the digital compass, the orientation of the system
can be found relative to magnetic north instead of gravity. Another option would
be to use a gyroscope. The motions relative to the gyroscope would provide a
good reference. If the GPS and power board were to be redesigned, one important
change should be made. On the new board, the GPS reset should be connected to
the GPS reader PIC. This would allow the PIC to reset the GPS if it did not
initialize properly.
The motor control system is a good system, but the jet drive system does not work
as anticipated. The motor control can be applied to a new drive system. Besides
the motor control systems, the current measuring device can also be used in part
to determine the power consumption of the motors with the new drive system. For
simplicity, the jet drive system could be replaced with a simple propeller system.
When the new drive system is installed the revolution circuitry can be utilized to
synchronize the engines.
73
Pic Basic Pro and C18 programming languages where both used during the course
of this project. Pic Basic Pro was a good starter language because simple
operation, many software based commands and it ability to work with several
series if PIC microcontrollers. C18 was a more complex programming language.
This complexity also made it much more powerful and versatile than the Pic
Basic Pro.
This project has examined many different technologies and combined some of
them in a new way to create a wireless data acquisition system for measuring the
dynamic conditions useful in determining hull performance. The results show that
most of the chosen data acquisition technologies work well, and the results also
identify weaknesses in analog signal conditioning and inclinometer used in the
system. The information gained will be applied in future tests and improvements
of the LOMAC as well as other projects requiring similar sensor and data
acquisition capabilities.
74
References
Adcock, E.; Bartlett, J.; Culliton, W.; Jordan, T.; Mau, J.; Bare, E.A.; Florance, J.; Kahng, S. (2001). “An embedded wireless data acquisition system for wind tunnel model applications”. ICIASF Record, International Congress on Instrumentation in Aerospace Simulation Facilities (pp. 327-336). Institute of Electrical and Electronics Engineers Inc.
Analog Devices. (2003). “Low-Cost, Ultracompact ±2 g Dual-Axis
Accelerometer”. ADXL311. Analog Devices. (2000). “Low-Cost ±2 g Dual-Axis Accelerometer with Duty
Cycle Output”. ADXL202E*. Bentham, Jeremy. (2002). TCP/IP LEAN: Web Servers for Embedded Systems
(2nd ed.). CMPBooks: Lawrence, KS “Bluetooth FAQ & Knowledge Base: What are some of the technical details of
the Bluetooth wireless specification?” Bluetooth.org- - The Official Bluetooth Membership Site June 2004. <https://www.bluetooth.org/admin/bluetooth2/faq/view_record.php?id=44>.
Burland, Travis & Mark Cencer & Patrick Hatton. (2003). “LOMAC Littoral-
Operation Multipurpose Auxiliary Craft”. Marine Field Projects Report, Florida Institute of Technology
Edwards, Dana B. (1998). “Mobile data acquisition using GPS and wireless
technologies”. Instrumentation in the Aerospace Industry : Proceedings of the International Symposium (pp. 425-433). ISA, Research Triangle Park, NC, USA
Florida Institute of Technology, University Publications. (2004) “Florida Tech
Campus Map”. Honeywell Sensor Products. (2003). “HMC1051/HMC1052/HMC1053”.
75
Lohachit, W.; Bachnak, R.; Michaud, P.; Duff, S.; Adams, J.; Steidley, C. (2003). “Wireless Data Acquisition and Logging in Shallow Water Environments”. IEEE International Symposium on Intelligent Control – Proceedings (pp. 980-984). Institute of Electrical and Electronics Engineers Inc.
Microchip Technology, Inc.(2004). “MCP601/602/603/604: 2.7V to 5.5V Single-
Supply CMOS Op Amps”. DS21314F. Mitchell, Kyle; Rao, Vittal S.; Pottinger, Hardy J. (2002). “Lessons learned about
wireless technologies for data acquisition”. Proceedings of SPIE - The International Society for Optical Engineering (pp. 331-341). The International Society for Optical Engineering
“NMEA 0183” DIE GPS-HOMEPAGE VON KLAUS H. HIRSCHELMANN .
August 2002. June 2004. <http://www.kh-gps.de/nmea-faq.htm>. Raygan, Robert E. (2002). “Wireless remote sensor data acquisition and
management using linux OS, MURS and 802.11b”. IEEE Vehicular Technology Conference (pp. 219-223). Institute of Electrical and Electronics Engineers Inc.
Rockwell Semiconductor Systems. (1998). ““Jupiter” Global Positioning System
(GPS) Receiver (Part No. TU30-D140-221/231)”. GD003E. Townsend, C.P.; Hamel, M.J.; Sonntag, P.; Trutor, B.; Arms, S.W. (2002).
“Scaleable, wireless web-enabled sensor networks”. Proceedings of SPIE - The International Society for Optical Engineering (pp. 1-9). The International Society for Optical Engineering
US Digital Corporation. (2004). “T2 Incremental Inclinometer”. Rev. 01.20.04.
T2. Winfield, A.F.T.; Holland, O.E. (2000, March). “Application of wireless local
area network technology to the control of mobile robots”. Microprocessors and Microsystems (pp. 597-607)
WIZnet. (2002). “i2Chip W3100A Technical Datasheet v1.3”
76
Appendix A: LOMAC Motor Drive Code '**************************************************************** ' 'Title: motorsl.bas Motor Controller ' 'Author: Douglas Guardino ' 'Compiler: Pic Basic Pro 2.42a ' 'Platform: PIC Microprocessor PIC16F876A @ 20 MHz ' 'Description: This program turns the PIC in to a I2C slave. The ' I2C slave address is read from Port B at the start ' of the program. The PIC outputs a pulse width ' modulated signal on Port C pin 1, based on a ' duty cycle receives from a I2C master. ' 'Credits: The code here is based on microEngineering Lab’s ' I2C slave example, 12cslave.bas available on ' http://www.melabs.com/resources/samples.htm ' '**************************************************************** ' PicBasic Pro I2C slave program - PIC16F877/PIC-X1 define OSC 20 'Tell compiler 20 MHz oscillator is used ' Alias pins scl VAR PORTC.3 ' I2C clock input sda VAR PORTC.4 ' I2C data input ' Define used register flags SSPIF VAR PIR1.3 ' SSP (I2C) interrupt flag BF VAR SSPSTAT.0 ' SSP (I2C) Buffer Full R_W VAR SSPSTAT.2 ' SSP (I2C) Read/Write D_A VAR SSPSTAT.5 ' SSP (I2C) Data/Address CKP VAR SSPCON.4 ' SSP (I2C) SCK Release Control SSPEN VAR SSPCON.5 ' SSP (I2C) Enable SSPOV VAR SSPCON.6 ' SSP (I2C) Receive Overflow Indicator WCOL VAR SSPCON.7 ' SSP (I2C) Write Collision ' Detect ' Allocate RAM datain VAR BYTE ' Data in dataout VAR BYTE[2] ' Data out array address var byte ' Internal address
77
speed var byte ' PWM value temp var byte outgoing var byte x var word servo var word mode var bit I2Caddress var byte trisb = $FF i2caddress = portb >> 1 speed = 0 datain = 0 trisc.2 = 0 HPWM 1, 0, 3767 goto init Disable i2cslave: ' I2C slave subroutine SSPIF = 0 ' Clear interrupt flag IF R_W = 1 Then i2crd ' Read data from us IF BF = 0 Then i2cexit ' Nothing in buffer so exit IF D_A = 1 Then i2cwr ' Data for us (not address) ' Clear the address from the buffer IF SSPBUF != I2Caddress Then i2cexit GoTo i2cexit i2cwr: ' I2C write data to us if mode = 0 Then address = SSPBUF ' set address value mode = 1 GoTo i2cexit endif if mode = 1 Then datain = SSPBUF mode = 0 GoTo i2cexit endif GoTo i2cexit
78
i2crd: ' I2C read data from us SSPBUF = dataout[address] ' Get data from array CKP = 1 ' Release SCL line mode = 0 ' set mode GoTo i2cexit ' That's it i2cexit: if SSPOV = 1 then mode = 0 SSPOV = 0 BF = 0 temp = SSPBUF endif Resume ' Return to main program Enable init: trisa = $ff trisc.0 = 1 trisc.3 = 1 trisc.4 = 1 ' Enable Inturupts and mask all non ssp ones INTCON = %11000000 PIE1 = %00001000 PIE2 = $00 ' Initialize ports and directions ADCON1 = %00000111 ' PORTA to digital ' Initialize I2C slave mode SSPADD = I2Caddress ' Set our address SSPCON2 = 0 ' General call address disabled SSPCON = $36 ' Set to I2C slave with 7-bit address option_reg.5 = 1 option_reg.4 = 0 option_reg.3 = 1 option_reg.2 = 0 option_reg.1 = 0 option_reg.0 = 0 t1con = %00000111
79
On Interrupt GoTo i2cslave GoTo mainloop ' Skip over subroutines mainloop: ' Main program loop if datain != speed then speed = datain HPWM 1, speed, 3767 endif goto mainloop end
80
Appendix B: R/C Interpolator Code '**************************************************************** ' 'Title: motorcon.bas R/C Interpolator Code ' 'Author: Douglas Guardino ' 'Compiler: Pic Basic Pro 2.40 ' 'Platform: PIC Microprocessor PIC16F876A @ 4 MHz ' 'Description: This program uses a PIC to interpret signals from ' a R/C receiver and turns them into duty cycles for ' the motor controllers. The duty cycle is ' transmitted to the motor controllers through the ' I2C bus. The R/C receiver channels are read on ' Port B Pin 0 (Power) and Port B Pin 1 ' (Differential). The I2C bus’s clock pin is Port B ' Pin 3 and the data pin is Port B Pin 2 ' '**************************************************************** ' Pin Aliases scl VAR PORTB.3 ' I2C clock sda VAR PORTB.2 ' I2C data ' Motor Controller I2C slave Addresses motorladdressL CON 2 motorladdressR CON 15 ' RAM alocation outdataL var byte outdataR var byte address var byte controlP var byte controlD var byte controlPold var byte controlDold var byte maxP var byte minP var byte maxD var byte minD var byte intensity var byte diff var byte diffq var byte ' Initialize Variables
81
outdataL = 0 outdataR = 0 controlPold = 0 controlDold = 0 maxP = 0 maxD = 0 minP = 0 minD = 0 intensity = 0 diff = 0 diffq = 0 ADCON1 = %00000111 'Sets the analog pins to digital mode trisa = $FF 'Sets Port A as inputs trisb = $00 'Sets Port B as outputs trisc = $00 'Sets Port C as outputs trisb.2 = 1 'Sets Port B pin 2 as an input trisb.3 = 1 'Sets Port B pin 3 as an input trisb.1 = 1 'Sets Port B pin 1 as an input trisb.0 = 1 'Sets Port B pin 0 as an input ' The program reads two channels from the R/C controller: ' Power and Differential. getspeed: wait01: pause 4 if portb.0 = 1 then wait01 'make sure the pin is in a known ' state pulsin portb.0, 1, controlP 'reads the pulse length for power wait02: if portb.1 = 1 then wait02 'make sure the pin is in a known ' state pulsin portb.1, 1, controlD 'reads the pulse length for
' differential ' adds padding to the last used value to reduce changes due to ' random fluctuations maxP = controlPold + 3 minP = controlPold - 3 maxD = controlDold + 3 minD = controlDold - 3 ' Check to see if there been significant change since the last ' used value. If there was it continues otherwise it goes and ' checks the R/C reciver again. if ( controlP <= maxP ) AND (controlP >= minP) AND ( controlD <= maxD ) AND (controlD >= minD)then
82
goto wait01 endif ' At this point updated the last used value controlPold = controlP controlDold = controlD ' Start of the control algorithm if controlP < 117 then intensity = 0 outdataL = 0 outdataR = 0 goto setspeed endif if controlP > 180 then intensity = 255 goto checkdiff endif intensity = (controlP - 117) * 4 checkdiff: if controlD < 149 then outdataR = intensity if controlD < 103 then outdataL = 0 goto setspeed endif diffq = (149 - controlD) diff = (diffq * 5) if diff > intensity then outdataL = 0 else outdataL = intensity - diff endif goto setspeed endif if controlD > 151 then outdataL = intensity if controlD > 192 then outdataR = 0 goto setspeed endif diffq = (controlD - 151) diff = (diffq * 6) if diff > intensity then outdataR = 0 else outdataR = intensity - diff
83
endif goto setspeed endif outdataR = intensity outdataL = intensity ' The control algorithm has determined the duty cycle for each ' engine and it need to be sent using the I2C bus to the motor ' controllers setspeed: address = 0 wd: i2cwrite sda, scl, motorladdressL, address, [outdataL] pause 70 wd2: i2cwrite sda, scl, motorladdressR, address, [outdataR] pause 70 ' Restarts the process over again goto getspeed
84
Appendix C: GPS Reader Code '**************************************************************** ' 'Title: gpsSlave.c GPS Reader Slave ' 'Author: Douglas Guardino ' 'Compiler: C18 v2.30 ' 'Platform: PIC Microprocessor PIC18F258 @ 40 MHz ' 'Description: This program uses a PIC to read the serial output ' of a GPS module and saves the GPRMC sentence and ' provided it for access over the I2C ' communications. The PIC is an I2C slave. ' '**************************************************************** #include <p18f258.h> #include <delays.h> #include <usart.h> #include <i2c.h> #include <string.h> char usartBuff[80], i2cBuff[80] = "hellol world ", inbuff[20], bufflength = 0, lastchar, temp, lastr = 0, nextw = 0, tag[8] = "$GPRMC,", status = 0; // high interrupts void int_handle (void); #pragma code HIGH_INTERRUPT_VECTOR = 0x8 void high_ISR (void) _asm goto int_handle _endasm #pragma code // this command gets a byte form the USART buffer and puts I in // the receive buffer and increments the end of buffer value void getbyte(void) inbuff[nextw] = ReadUSART(); // gets USART byte nextw ++; // increments the buffer
// index
85
if (nextw >= 20) // checks for buffer wrap around nextw = 0; PIR1bits.RCIF = 0; // Clears USART interrupt flag // interrupt handler // handles the interrupt generat4ed by the an I2C reception #pragma interrupt int_handle void int_handle (void) char length = 0; INTCON = 0; PIR1 = 0; // clears all interrupts // If a Read request is received it transmits the GPS
// sentence stored if (SSPSTATbits.R_W == 1) for(length = 0; length < 80; length++) PIR1bits.SSPIF = 0 ; SSPBUF = i2cBuff[length]; SSPCON1bits.CKP = 1; if(PIR1bits.RCIF) getbyte(); while ( !PIR1bits.SSPIF ); // Handles any other I2C conditions, by ignoring them if (SSPSTATbits.D_A == 1) temp = SSPBUF; if (SSPBUF != 0x0F) temp = SSPBUF; if (SSPCON1bits.SSPOV == 1) SSPCON1bits.SSPOV = 0; SSPSTATbits.BF = 0; temp = SSPBUF; SSPCON1bits.CKP = 1; // enables the interrupt INTCON = 0b11000000; // This command gets a byte out of the receive buffer If there // nothing in the buffer it wait for the next byte to be received // It then updates the buffer indexes. int getlast(void) char current; current = lastr; lastr++;
86
if (lastr >= 20) lastr = 0; // If the buffer is empty wait for data to be received if (current == nextw) while(!DataRdyUSART()); getbyte(); // Returns the last byte received return inbuff[current]; void main (void) // Initialize the USART port OpenUSART( USART_TX_INT_OFF & // TX interrupt off USART_RX_INT_OFF & // RX interrupt off USART_ASYNCH_MODE & // Asynchronous mode USART_EIGHT_BIT& // 8-Bit USART_CONT_RX & // Continuous receive USART_BRGH_LOW, // Low Baud rate formula 129); // set approximately 4800 bps // Initialize the I2C port in slave mode OpenI2C( SLAVE_7, SLEW_ON); // I2C master mode 100kHz mode SSPADD = 0x0F; // Sets the slave address to 0x0F TRISC = 0xFF; SSPCON1bits.CKP = 1; memset(usartBuff, 0, 80); // clears the incoming buffer // Initializes the interrupt setting, setting it to
// interrupt on I2C receive. INTCON = 0b11000000; INTCON2 = 0; INTCON3 = 0; PIE1 = 0b00001000; PIE2 = 0; // Repeats this code endlessly // This code searches for the GPRMC sentence tag // It compares the incoming serial data to a known string
// to find the GPRMC tag it then moves the rest of the // sentence into a receiving buffer till the end of // sentence character is received. It then copies it to the // output buffer.
while(1) lastchar = 0; status = 0;
87
while(status != 7) lastchar = getlast(); if(tag[status] == lastchar) status++; else status = 0; bufflength = 0; while(lastchar != 10) lastchar = getlast(); usartBuff[bufflength] = lastchar; bufflength++; usartBuff[bufflength] = 0; strcpy( i2cBuff, usartBuff); memset(usartBuff, 0, 80);
88
Appendix D: Inclinometer Slave Code '**************************************************************** ' 'Title: incloslave.c Inclinometer Slave ' 'Author: Douglas Guardino ' 'Compiler: C18 v2.30 ' 'Platform: PIC Microprocessor PIC18F258 @ 40 MHz ' 'Description: This program uses a PIC to read quadrature signal ' outputted by the inclinometer. The PIC has an ' internal counter that is initialized at start up. ' This counter can be accessed over the I2C bus. ' The PIC is set up as an I2C slave. The system will ' Interrupt on changed in either Port B pins 4 and 5 ' these pins are hooked to the inclinometer. ' '**************************************************************** #include <p18f258.h> #include <i2c.h> int incl = 0; // set the angle to 0 unsigned char * inclpt; char temp, BLast = 0, QuadTable[4][4] = 0,-1, 1, 0, 1, 0, 0,-1, -1, 0, 0, 1, 0, 1,-1, 0; // The above table tells the program how to increment the counter // based on the last state and the current state of the pins. // high interupts void int_handle (void); #pragma code HIGH_INTERRUPT_VECTOR = 0x8 void high_ISR (void) _asm goto int_handle _endasm #pragma code #pragma interrupt int_handle
89
void int_handle (void) char BNow; BNow = PORTB & 0b00110000; //this masks the unused bits BNow = BNow >> 4; //this moves the used bit to LSB incl += QuadTable[BNow][BLast]; // This them increment the // the counter based on the
// table BLast = BNow; // updates the last state INTCON = 0b10001000; // initialize interrupt void main (void) // initialize parameters
char length = 0; BLast = PORTB & 0b00110000; // gets initial state BLast = BLast >> 4; OpenI2C( SLAVE_7, SLEW_ON); SSPADD = 0x08; // sets the I2C slave address to 0x08 TRISC = 0xFF; TRISB = 0xFF; SSPCON1bits.CKP = 1; inclpt = (unsigned char *)&incl; // initialize the pointer // initialize interrupt INTCON = 0b10001000; INTCON2 = 0; INTCON3 = 0; PIE1 = 0b00000000; PIE2 = 0; // repeat this code constantly // this code check to see it there has been a read request // on the I2C for the inclinometer angle it then transmits // the angle back. while (1) if(PIR1bits.SSPIF) PIR1 = 0; if (SSPSTATbits.R_W == 1) for(length = 0; length < 2; length++) PIR1bits.SSPIF = 0 ; SSPBUF = inclpt[length]; SSPCON1bits.CKP = 1; while ( !PIR1bits.SSPIF ); if (SSPSTATbits.D_A == 1) temp = SSPBUF; if (SSPBUF != 0x0F)
90
temp = SSPBUF; if (SSPCON1bits.SSPOV == 1) SSPCON1bits.SSPOV = 0; SSPSTATbits.BF = 0; temp = SSPBUF; SSPCON1bits.CKP = 1;
91
Appendix E: PICNIC Code '**************************************************************** ' 'Title: picnici2c.c PICNIC code ' 'Author: Douglas Guardino ' 'Compiler: C18 v2.30 ' 'Platform: PIC Microprocessor PIC18F458 @ 40 MHz ' 'Description: This program uses a PIC as the central processing ' unit of a system of sensors. It gets analog ' information on analog channels 0 – 6. It also gets ' GPS and Inclination over the I2C bus from other ' devices. It also uses the I2C buss to communicate ' with the IIM710A. ' '**************************************************************** #include <p18f458.h> #include <delays.h> #include <usart.h> #include <i2c.h> #include <string.h> #include <stdlib.h> #include <adc.h> #include <timers.h> // initialize global parameters unsigned char status, buffer[80], temp[10]; char charbuff[10], ackstat = 0; int doug, time = 0, timelast; unsigned long before, after; rom char initStMsg[] = "Initilazation Status "; rom char socketInitStMsg[] = "Socket Initilazation Status "; rom char WaitConectMsg[] = "Waiting for connection"; rom char conectEstabMsg[] = "Connection Established"; rom char welcomeMsg[] = "Good Morning"; // high interupts void int_handle (void); #pragma code HIGH_INTERRUPT_VECTOR = 0x8 void high_ISR (void) _asm
92
goto int_handle _endasm #pragma code // this interrupt is generated every time Timer0 overflows. // This happens every millisecond. This handler re-setup the // timer and increments millisecond counter. #pragma interrupt int_handle void int_handle (void) WriteTimer0(55535); time++; INTCON = 0b10100000; // this command was written to transmit data over the I2C buss // it takes the control address of the device, a 2-byte address, // a pointer and the number of bytes to be transmitted. void i2cTx( unsigned char control, unsigned char addressHigh, unsigned char addressLow, unsigned char *array, unsigned char length) unsigned char count; IdleI2C(); StartI2C(); while ( SSPCON2bits.SEN ); control = control & 0xFE; WriteI2C ( control); IdleI2C(); WriteI2C ( addressHigh); IdleI2C(); WriteI2C ( addressLow); for(count = 0; count < length; count++) IdleI2C(); WriteI2C ( array[count]); IdleI2C(); StopI2C(); while ( SSPCON2bits.PEN ); // this command was written to receive data over the I2C buss // it takes the control address of the device, a 2-byte address, // a pointer and the number of bytes to be transmitted. // This command transmits the address before requesting a read. unsigned char * i2cRx( unsigned char control, unsigned char addressHigh, unsigned char addressLow,
93
unsigned char *array, unsigned char length) unsigned char count; IdleI2C(); StartI2C(); while ( SSPCON2bits.SEN ); control = control & 0xFE;
WriteI2C ( control); IdleI2C(); WriteI2C (addressHigh); IdleI2C(); WriteI2C ( addressLow); IdleI2C(); StopI2C(); while ( SSPCON2bits.PEN ); control = control | 0x01; IdleI2C(); StartI2C(); while ( SSPCON2bits.SEN ); WriteI2C ( control); SSPCON2bits.RCEN = 1; for(count = 0; count < length; count++) IdleI2C(); array[count] = ReadI2C(); if (count == length -1) NotAckI2C(); else AckI2C(); IdleI2C(); StopI2C(); while ( SSPCON2bits.PEN ); return(array); // This command initializes the IIM7010A with the commented // values unsigned char InitWiznet( unsigned char control)
94
unsigned char data; // initilise IINCHIP // Gatway Address buffer[0] = 192; //80 buffer[1] = 168; //81 buffer[2] = 1; //82 buffer[3] = 1; //83 // Subnet Mask buffer[4] = 255; //84 buffer[5] = 255; //85 buffer[6] = 255; //86 buffer[7] = 0; //87 //MAC Address buffer[8] = 0x00; //88 buffer[9] = 0xA0; //89 buffer[10] = 0x24; //8A buffer[11] = 0xBB; //8B buffer[12] = 0xD8; //8C buffer[13] = 0x6A; //8D // IP Address buffer[14] = 192; //8E buffer[15] = 168; //8F buffer[16] = 1; //90 buffer[17] = 50; //91 // Initial Retry Timer - value buffer[18] = 0x03; //92 100ms buffer[19] = 0xE8; //93 //Retry Count buffer[20] = 255; //94 // RX data Memory size buffer[21] = 0b000011; //95 8kb to ch 0 // TX data Memory size buffer[22] = 0b000011; //96 8kb to ch 0 //Write all that to the IINCHIP i2cTx( control, 0x00, 0x80, buffer, 23); buffer[0] = 0x01; //Sends the initialze command i2cTx( control, 0x00, 0x00, buffer, 1);
95
//Checks status of initilazation i2cRx( control, 0x00, 0x04, &data, 1); //Returns the result of the initilazation return(data); // this command initializes ch0 to commented parameters. unsigned char initSocketCh0( unsigned char control, unsigned char hport, unsigned char lport) unsigned char data; // set SOPR register data = 0x01; //TCP communications i2cTx( control, 0x00, 0xA1, &data, 1); // set SPR registers, sets the port to listen on buffer[0] = hport; buffer[1] = lport; i2cTx( control, 0x00, 0xAE, buffer, 2); // set TOSR register to 1 // data alreadyt = 1 so it will not be set again i2cTx( control, 0x00, 0xB1, &data, 1); // set transmisoin pointers memset(buffer, 0, 10); // clears the first 10 buffer byes // set C0_TW_PR 01 - 04 to 0 // set C0_TR_PR 01 - 04 to 0 i2cTx( control, 0x00, 0x40, buffer, 8); // set C0_TA_PR 01 - 04 to 0 i2cTx( control, 0x00, 0x18, buffer, 4); // initilise socket data = 0b00000010; i2cTx( control, 0x00, 0x00, &data, 1); //clear interupts data = 0xFF; i2cTx( control, 0x00, 0x08, &data, 1); //check if socket initilized i2cRx( control, 0x00, 0x04, &data, 1); return(data); // this command outputs a string of a defined length on the // serial port, which an LCD screen is connected
96
void stringUARTS(char * string, unsigned char length) unsigned char x; for( x = 0; x < length; x++) while (BusyUSART()); WriteUSART(string[x]); return; // this command receives data from the IIM7010A and displays it // on the LCD screen int reciveData(unsigned char control)
unsigned char C0_RW_PR[4], C0_RR_PR[4], data, adhigh, adlow, rxlength = 0;
unsigned int counter, rstart, rend; memset(C0_RW_PR, 0, 4); memset(C0_RR_PR, 0, 4); // get pointers for recived data //check shadow pointer C0_SRW_PR i2cRx( control, 0x01, 0xE0, &data, 1); //wait 20 clock cycles Delay10TCYx(2); //Get the C0_RW_PR pointers i2cRx( control, 0x00, 0x10, C0_RW_PR, 4); //check shadow pointer C0_SRR_PR i2cRx( control, 0x01, 0xE1, &data, 1); //wait 20 clock cycles Delay10TCYx(2); //Get the C0_RR_PR pointers i2cRx( control, 0x00, 0x14, C0_RR_PR, 4); //Convert pointer into offsets rstart = C0_RR_PR[2]; rstart = rstart << 8; rstart &= 0x1F00; rstart += C0_RR_PR[3]; rend = C0_RW_PR[2] ; rend = rend << 8; rend &= 0x1F00;
97
rend += C0_RW_PR[3]; //Find lenght of information in buffer if(rend > rstart) counter = rend - rstart; data = 0; else counter = (rend + 0x1FFF) - rstart; data = 1; if(rend == rstart) return(0); rxlength = 0; while(counter) adhigh = rstart >> 8; adhigh += 0x60; adlow = rstart & 0x00FF; if( counter < 80) rxlength = counter; else rxlength = 80; if ( (rstart + rxlength) > 0x1FFF) rxlength = 0x2000 - rstart; i2cRx( control, adhigh, adlow, buffer, rxlength); stringUARTS((char *)buffer, rxlength); rstart += rxlength; if (rstart > 0x1FFF) rstart -= 0x2000; counter -= rxlength; i2cTx( control, 0x00, 0x14, C0_RW_PR, 4); data = 0b01000000; i2cTx( control, 0x00, 0x00, &data, 1); return(1); // This command transmits data using the IIM7010A void trasmitData( unsigned char control, unsigned char * string, unsigned char length)
98
unsigned char C0_TW_PR[4], data, adhigh, adlow,
txlength, offset = 0;
unsigned char * TW; unsigned int counter, tstart, tend; unsigned long C0_TW; char y; TW = (unsigned char *)&C0_TW; // get pointers for received data //check shadow pointer C0_STW_PR i2cRx( control, 0x01, 0xF0, &data, 1); //wait 20 clock cycles Delay10TCYx(2); //Get the C0_TW_PR pointers i2cRx( control, 0x00, 0x40, C0_TW_PR, 4); y = 3; for(y = 3; y >= 0; y--) TW[y] = C0_TW_PR[3 - y]; before = C0_TW; C0_TW += length; after = C0_TW; //Convert pointer into offsets tstart = C0_TW_PR[2]; tstart = tstart << 8; tstart &= 0x1F00; tstart += C0_TW_PR[3]; while(length) adhigh = tstart >> 8; adhigh += 0x40; adlow = tstart & 0x00FF; if ( (tstart + length) > 0x1FFF) txlength = 0x2000 - tstart; else txlength = length;
99
i2cTx( control, adhigh, adlow, string + offset, txlength);
tstart += txlength; if (tstart > 0x1FFF) tstart -= 0x2000; length -= txlength; offset += txlength; for(y = 3; y >= 0; y--) C0_TW_PR[y]= TW[3 - y] ; // Update the C0_TW_PR pointers i2cTx( control, 0x00, 0x40, C0_TW_PR, 4); // Execute a send comand data = 0b00100000; i2cTx( control, 0x00, 0x00, &data, 1); return; // this command converts an integer saving a 4 significant digit // 3 decimal place number into an ASCII string char * asciAcell(int value, char * string) int letter; if (value < 0) value = value * -1; string[0] = 45; else string[0] = 32; letter = value / 1000; value = value - (1000 * letter); string[1] = letter + 48; string[2] = 46; letter = value / 100; value = value - (100 * letter); string[3] = letter + 48; letter = value / 10; value = value - (10 * letter); string[4] = letter + 48; string[5] = value + 48; return(string); // This command gets the acceleration from specified channel and // places it in specified array.
100
char * getacell(char chan, char * outputB) int acell; unsigned int acell_16 = 0 ; char x; short long voltage; if( chan == 0) SetChanADC(ADC_CH0); if( chan == 1) SetChanADC(ADC_CH1); if( chan == 2) SetChanADC(ADC_CH2); if( chan == 3) SetChanADC(ADC_CH3); Delay10TCYx(7); for( x = 0; x < 16; x++) ConvertADC(); while(BusyADC()); acell = ReadADC(); acell_16 += acell; acell = acell_16 >> 4; doug = acell; acell -= 511; voltage = acell; voltage = voltage * 1000; voltage = voltage / 204; //205 acell = voltage; asciAcell(acell, outputB); outputB[6] = 32; if( chan == 0) outputB[7] = 90; // “Z” if( chan == 1) outputB[7] = 89; // “Y” if( chan == 2) outputB[7] = 90; // “Z” if( chan == 3) outputB[7] = 88; // “X” outputB[8] = 13; // CR outputB[9] = 10; // LF return(outputB); // this command read the remaining analog channels (digital // compass and optional one) and puts the results in a string char * getanalog(char * outputB) int NS = 0, EW = 0, power = 0, NS16 = 0, EW16 = 0,
power16 = 0, x; char stringL; short long voltage; SetChanADC(ADC_CH4);
101
Delay10TCYx(7); for( x = 0; x < 16; x++) ConvertADC(); while(BusyADC()); NS = ReadADC(); NS16 += NS; SetChanADC(ADC_CH5); Delay10TCYx(7); for( x = 0; x < 16; x++) ConvertADC(); while(BusyADC()); EW = ReadADC(); EW16 += EW; NS = NS16 >> 4; EW = EW16 >> 4; SetChanADC(ADC_CH6); Delay10TCYx(7); for( x = 0; x < 16; x++) ConvertADC(); while(BusyADC()); power = ReadADC(); power16 += power; power = power16 >> 4; itoa( NS, charbuff); strcpy(outputB, charbuff); stringL = strlen(outputB); outputB[stringL] = 32; outputB[stringL+1] = 0; itoa( EW, charbuff); strcat(outputB, charbuff); stringL = strlen(outputB); outputB[stringL] = 32; outputB[stringL+1] = 0; voltage = power; voltage = voltage * 1000; voltage = voltage / 205; power = voltage; asciAcell(power, charbuff); charbuff[6] = 32; charbuff[7] = 86; charbuff[8] = 0; strcat(outputB, charbuff); stringL = strlen(outputB); outputB[stringL] = 32; outputB[stringL+1] = 0; return (outputB);
102
void main (void) unsigned char wiznet = 0b10101010, length; unsigned int y; int pitch, roll; // initialize PIC peripherals OpenUSART( USART_TX_INT_OFF & // TX interrupt off USART_RX_INT_OFF & // RX interrupt off USART_ASYNCH_MODE & // Asynchronous mode USART_EIGHT_BIT& // 8-Bit USART_CONT_RX & // Continuous receive USART_BRGH_LOW, // Low Baud rate formula 64); // set approximately 9.6 kbs // initialize the I2C OpenI2C( MASTER, SLEW_ON); // I2C master mode 100kHz mode SSPADD = 99;
// initialize the analog channels OpenADC( ADC_FOSC_64 & ADC_RIGHT_JUST & ADC_8ANA_0REF, ADC_CH0 & ADC_INT_OFF); TRISA = 0xFF; TRISE = 0x0F;
// initialize the timer 0 OpenTimer0( TIMER_INT_OFF & T0_16BIT & T0_SOURCE_INT & T0_EDGE_FALL & T0_PS_1_1 ); TRISD = 0xFF; LATD = 255; WriteUSART( 12 ); // 12 clears the LCD screen // wait for screen to finish clearing Delay10KTCYx(50); while (BusyUSART()); putrsUSART( welcomeMsg); // wait .5 sec and then clear screen Delay10KTCYx(250);
103
Delay10KTCYx(250); WriteUSART( 12 ); // wait for screen to finish clearing Delay10KTCYx(50); status = 0; // initialize the IINCHIP status = InitWiznet(wiznet); // clear buffer memset(buffer, 0, 80); // out puts result of initialization to LCD // a result of 1 means the system initialized while (BusyUSART()); putrsUSART( initStMsg ); while (BusyUSART()); putsUSART( btoa(status, charbuff) ); while (BusyUSART()); WriteUSART( 10 ); // this code continually repeats. while(1) // socket initialization // setting ch0 listen on port 23 for a connection status = initSocketCh0( wiznet, 0, 23); // clear buffer memset(buffer, 0, 10); // out puts result of initialization to LCD // a result of 2 means the socket initializes while (BusyUSART()); putrsUSART( socketInitStMsg ); while (BusyUSART()); putsUSART( btoa(status, charbuff)); while (BusyUSART()); WriteUSART( 10 ); // now listen for a connection wait for a connection; buffer[0] = 0b00001000; i2cTx( wiznet, 0x00, 0x00, buffer, 1); while (BusyUSART()); putrsUSART( WaitConectMsg); while (BusyUSART()); WriteUSART( 10 );
104
// check the Socket State Register for ch0 // a value of 0x06 means a connection has been
// established while (status != 0x06) // Delay10KTCYx(1); // while not connected display the accelerations for
// calibration getacell(0, charbuff); charbuff[8] = 13; while (BusyUSART()); WriteUSART(32); stringUARTS(charbuff, 9);
getacell(1, charbuff); charbuff[8] = 13; while (BusyUSART()); WriteUSART(32); stringUARTS(charbuff, 9); getacell(2, charbuff); charbuff[8] = 13; while (BusyUSART()); WriteUSART(32); while (BusyUSART()); WriteUSART(32); stringUARTS(charbuff, 9);
getacell(3, charbuff); charbuff[8] = 13; while (BusyUSART()); WriteUSART(32); while (BusyUSART()); WriteUSART(32); stringUARTS(charbuff, 9); // displays the other analog channel
// information getanalog((char *) buffer);
length = strlen((char *)buffer); while (BusyUSART()); WriteUSART(32); while (BusyUSART()); WriteUSART(32); stringUARTS((char *)buffer, length); // reads the inclination and displays it i2cRx( 0x08, 0x00, 0xA0, (
unsigned char *)&pitch, 2); itoa( pitch, (char *)buffer);
105
length = strlen((char *)buffer); buffer[length] = 13; length ++; buffer[length] = 0; stringUARTS((char *)buffer, length); // wait .2 sec Delay10KTCYx(200); WriteUSART( 12 ); // wait for screen to finish clearing Delay10KTCYx(60); // check to see if there is a connection i2cRx( wiznet, 0x00, 0xA0, &status, 1); // connection established while (BusyUSART()); putrsUSART( conectEstabMsg); // wait 1 sec and then clear screen Delay10KTCYx(250); Delay10KTCYx(250); Delay10KTCYx(250); Delay10KTCYx(250); WriteUSART( 12 ); // wait for screen to finish clearing Delay10KTCYx(50); // enables the interrupt for the timer INTCON = 0b10100000; // while the connection is open do all this stuff while (status == 0x06) // check the receive buffer to see if there is
// any incoming data for the LCD screen and // output it (disabled) // reciveData(wiznet); // make sure the millisecond counter is within
// the limit if(time > 1000) time = 0; // captures the millisecond counter timelast = time; // reduces the number of transmissions // it transmits the non GPS data every
// 40 milliseconds
106
if ( timelast % 40 == 0) getacell(0, charbuff); charbuff[8] = 32; charbuff[9] = 0; strcpy((char * )buffer, charbuff); getacell(1, charbuff); charbuff[8] = 32; charbuff[9] = 0; strcat((char * )buffer, charbuff); getacell(2, charbuff); charbuff[8] = 32; charbuff[9] = 0; strcat((char * )buffer, charbuff); getacell(3, charbuff); charbuff[8] = 32; charbuff[9] = 0; strcat((char * )buffer, charbuff); length = strlen((char *) buffer); trasmitData(wiznet,buffer,length); getanalog ((char *)buffer); i2cRx( 0x08, 0x00, 0xA0, (
unsigned char *)&pitch, 2); itoa( pitch, charbuff); strcat((char * )buffer, charbuff); length = strlen((char *)buffer); buffer[length] = 32; length++; buffer[length] = 0; length++; itoa( timelast, charbuff); strcat((char * )buffer, charbuff); length = strlen((char *)buffer); if(timelast == 1000) buffer[length] = 32; length ++; else buffer[length] = 10; length ++; buffer[length] = 13; length ++; trasmitData(wiznet,buffer,length);
107
// transmit the GPS data once a second and // reset the millisecond counter
if( timelast == 1000) // 275 // access the GPS and get last update i2cRx( 0x0F, 0x00, 0x00, buffer, 80); // transmit the last updata length = strlen((char *)buffer); trasmitData(wiznet,buffer, length); time -= 1000; // Check the current connection status i2cRx( wiznet, 0x00, 0xA0, &status, 1);
108
Appendix F: Motor Driver Schematic
109
Appendix G: R/C Interpolator Schematic
110
Appendix H: Power and GPS Board Schematic
111
Appendix I: Accelerometer Board Schematic
112
Appendix J: PICNIC Board Schematic
113
Appendix K:Florida Tech Campus (Florida Institute of Technology, 2004)
114
Appendix L: Boat Test - Acceleration Data
115
Appendix M: Car Test 1 – Acceleration
116
Appendix N: Car Test 1 - Acceleration and Inclinometer
117
Appendix O: Car Test 2 - Accelerations and Inclination
118
Appendix P: Car Test 3 - Acceleration and Inclination
119
120