cover page goes here

1
Title: Underwater Remotely-Operated Vehicle
Author: Scott O’Brien
Supervisor: Dr. Andrzej Tarczynski
Date: May 2012
Course: B.Eng. Electronic Engineering

2
Abstract The aim of this project is to design and construct an underwater,
remotely-operated vehicle (ROV), fitted with a 4-axis positioning
system, a video transmission system, and a 2-axis (pitch and roll)
control system to assist imaging and positional stability.

The project includes the design and development of the PVC frame and
water-proof enclosure, design and development of an ARM Cortex-M3
microcontroller-based electronic circuit for the operator interface, and
another ARM Cortex-M3 microcontroller-based electronic circuit that
controls the seven DC motors fitted with propellers.

A fully operational vehicle has been constructed, though the 2-axis

control system and video transmission system remain incomplete.

3
Contents

Acknowledgements ................................................................................................................................ 7
Glossary .................................................................................................................................................. 8
1. Introduction ....................................................................................................................................... 9
1.1 Why Build an ROV? ................................................................................................................... 9
1.2 Why Include a Self-Stabilising Control System?...................................................................... 9
1.3 Report Structure.......................................................................................................................... 9
1.4 An Introduction to Underwater Vehicles ................................................................................ 10
2. System Requirements and Architecture ........................................................................................ 13
3. Mechanical Design and Construction ............................................................................................ 14
3.1 Frame Design ............................................................................................................................. 14
3.2 Frame Construction .................................................................................................................. 14
3.3 Water-Proof Enclosure Design and Construction .................................................................. 15
3.4 Propulsion by Thrusters ........................................................................................................... 17
3.5 Tether ......................................................................................................................................... 21
4. Top Controller ................................................................................................................................. 23
4.1 Top Controller Design............................................................................................................... 23
4.2 Construction and Testing ......................................................................................................... 23
4.3 mbed Rapid Prototyping Development System ...................................................................... 24
4.4 Power Supply ............................................................................................................................. 24
4.5 LCD Display............................................................................................................................... 25
4.6 Analog Joysticks ........................................................................................................................ 25
4.7 Temperature Sensor .................................................................................................................. 25
4.8 Water Leak Detection Warnings ............................................................................................. 26
4.9 Switches and LED’s................................................................................................................... 26
4.10 Data Communications ............................................................................................................. 26
5. Bottom Controller ........................................................................................................................... 29
5.1 Bottom Controller Design ......................................................................................................... 29
5.2 Construction and Testing ......................................................................................................... 29
5.3 mbed Rapid Prototyping Development System ...................................................................... 30
5.4 Inertial Measurement Unit ....................................................................................................... 30
5.5 Leak Detector............................................................................................................................. 30
5.6 Temperature Sensor .................................................................................................................. 31
5.7 Power Supply ............................................................................................................................. 31

4
 5.8 MOSFET’s ................................................................................................................................. 32
5.9 H-Bridges ................................................................................................................................... 32
5.10 Data Communications ............................................................................................................. 34
5.11 Video Camera .......................................................................................................................... 34
5.12 Lights ........................................................................................................................................ 34
5.13 Data Logger ............................................................................................................................. 35
5.14 Depth Sensor ............................................................................................................................ 35
5.15 Software.................................................................................................................................... 35
6. Self-Stabilising Control System ...................................................................................................... 37
6.1 Control System Theory ............................................................................................................. 37
6.2 Self-Stabilising System Overview............................................................................................. 37
6.3 P Controllers .............................................................................................................................. 38
6.4 PID Controllers.......................................................................................................................... 39
6.5 Implementing a PID Controller ............................................................................................... 42
6.6 Building a Model of the Pitch Control System ....................................................................... 42
6.7 Additional Aspects of the Self - Stabilising Control System as Implemented ...................... 43
7. Testing and Measurement .............................................................................................................. 44
7.1 Testing the Electronic Circuits ................................................................................................. 44
7.2 Testing the Tether and the Wiring........................................................................................... 44
7.3 Water-Proof Testing of the Enclosure ..................................................................................... 45
7.4 Trim Testing .............................................................................................................................. 45
7.5 Powered Testing ........................................................................................................................ 46
7.6 Measurements of Dynamics Characteristics for Control System Development .................. 47
8. Conclusions ...................................................................................................................................... 50
8.1 Results ........................................................................................................................................ 50
8.2 Analysis ...................................................................................................................................... 50
8.3 Future Work .............................................................................................................................. 51
8.4 Alternative Approaches ............................................................................................................ 52
8.5 Summary .................................................................................................................................... 52
9. References ........................................................................................................................................ 53
10. Bibliography .................................................................................................................................. 55
11. Appendices ..................................................................................................................................... 56
Appendix A - DES Project Specification Form ............................................................................ 56
Appendix B - Top Controller Schematics ..................................................................................... 57

5
Appendix C - Bottom Controller Schematics ............................................................................... 59
Appendix D - Top Controller Code ............................................................................................... 61
Appendix E - Bottom Controller Code .......................................................................................... 71
Appendix F - Data Logging Code .................................................................................................. 78
Appendix G - IMU Schematic and PCB Design ........................................................................... 83
Appendix H - Definitions of Motion............................................................................................... 85
Appendix I - Accelerometer Noise Analysis .................................................................................. 86
Appendix J - Bill of Materials ........................................................................................................ 88
Appendix K - Permissions .............................................................................................................. 91
Appendix L - Workplan .................................................................................................................. 93
Appendix M - Disk Contents .......................................................................................................... 94

6
Acknowledgements
I would like to take this opportunity to thank my partner Anne Donald, my Project
Supervisor at the University of Westminster, Dr. Andrzej Tarczynski, and Jack Bowles
and Colin Pullen from the Lodge Scuba Diving Club for all their support and help.

In addition, the following people helped considerably:

 Dr Mohammed Al-Janabi , Dr Viv Bartlett, John McNamara, Professor Izzet Kale,

Karl Kowalczy and Mukesh Popat at the University of Westminster.
 Jane Clegg, Hazel Fraser, Fion Gunn, Kay Trotter, Carol Walker and Stephen
Wiltshire from the Stanthorpe Triangle Residents Association.
 Paul Hoy, Simon Lodge, Sarah Morgan, Mitch Pluck-Wyatt, and John Porterhouse
from the Lodge Scuba Diving Club
 Martin Evans
 Chris Styles and Simon Ford at mbed.com
 Robert Forsyth, Silogini Gnanasundaram, Raji Guhanesan, and Robert Karpinski at
the University of Westminster
 Tim Marvin

And the following companies for their support:

 AbPlas
 ARM Holdings Ltd
 Elektron Technology
 Exar Corporation
 Keller UK Ltd
 Northern Connectors
 RelChron Limited
 Saab Seaeye
 SMD Ltd
 VideoRay LLC
 Woods Hole Oceanographic Institution

7
Glossary

Ballast: weights used to offset buoyancy

Buoyancy: the tendency to float
Centroid: the mid-point between the centre-of-mass and centre-of-buoyancy
DOF: degrees of freedom, the number of independent axes
Heave: to move up and down
IC: integrated circuit
IMU: inertial measurement unit
IP68-rated: an industry “standard” for rating environment-proofed components
kbps: a data rate of kilobits per second
Manipulator: a robotic claw or tool
Pitch: as in nodding your head up and down
PWM: pulse width modulation, used for proportional speed control
Roll: as in tilting your head to one side
ROV: remotely-operated vehicle
Surge: to move forwards and backwards
Sway: to move from side-to-side
Thruster: motor fitted with a propeller, used for propulsion and positioning
Trimming: positioning of ballast and buoyancy elements to level the ROV
Weight-in-air: the weight of the ROV out of the water
Yaw: as in turning your head to the side

8
1. Introduction any load variation. If the ROV collects for
example a soil sample, the variation in the
1.1 Why Build an ROV? mass (and the corresponding variation in
the position of the centre-of-mass) will
The purpose of this project is to design and cause a tilt and so negate the careful
construct a remotely-operated underwater trimming previously performed.
vehicle (ROV) fitted with a 4-axis positioning
system, and a self-stabilising 2-axis control Most simple ROV’s do not include any
system. The many varied aspects of this project automated self-stabilising ability, due to the
present quite a number of challenges and added cost and complexity, and simply accept
learning opportunities: the problems that occur. For larger,
commercial ROV’s however, particularly those
 design and construction of an electronic that have manipulators where the mass
operator interface distribution will vary during a voyage, a self-
stabilising system would seem to be a
 design and construction of an electronic
requirement. Somewhat surprisingly, they are
DC motor drive system
usually only found on the most expensive,
 design and construction of a water-proof
most robust vehicles available. The “Seaeye”
enclosure mounted on an appropriate frame
range from SAAB for example, currently has 9
 research, design and implementation of a models ranging in size from 60 kg through to
level measurement system 1,500 kg (weight-in-air) and it is only the
 research, design and implementation of a biggest, most expensive model, the Jaguar,
self-stabilising control system which is fitted with an automatic pitch / roll
stabilising function [1].
This ROV project ultimately represents an
overlap of interests: control systems, Accordingly, an investigation into the
underwater exploration, and electronics. design and application of a control system to
augment the natural positioning of underwater
1.2 Why Include a Self-Stabilising vehicles, in particular the smaller vehicles,
Control System? seems to be a worthwhile and practical
undertaking.
All objects in water, including underwater
vehicles, will find their natural disposition in 1.3 Report Structure
water due to gravity acting upon their mass and
relative buoyancy. This position however may The remainder of this first Chapter gives an
not be level, which in the case of an introduction to the world of underwater
underwater vehicle makes positioning and vehicles, their classifications and their
imaging problematic. This issue is usually commercial uses.
minimised by careful trimming i.e. locating of
ballast and buoyancy elements on the vehicle, Chapter Two gives a brief overview of the
but this is not an ideal solution. ROV system architecture that was developed.

There are two main problems with relying Chapters Three, Four and Five detail the
solely on accurate trimming: design and construction of the hardware and
electronic elements.
 Firstly, it cannot compensate for
unpredictable external influences such as Chapter Six follows with details of the self-
strong currents. It may not be obvious from stabilising control system implemented and
the surface but undersea currents are Chapter Seven summarises the testing and
typically not parallel to the water surface tuning processes once the ROV was actually in
and commonly have a significant vertical the water.
component.
The report conclusions are contained in
 Secondly, trimming at the surface prior to Chapter Eight, followed by the official Project
commencing a voyage does not allow for

9
Specification, References and Bibliography 1.4.3 Autonomously Operated
sections, and finally the Appendices. Underwater Vehicles

1.4 An Introduction to Underwater An autonomously-operated underwater

Vehicles vehicle is designed to work without an
operator and without a direct connection to the
Underwater vehicles can be broadly surface. They are usually designed for a
classified as either: specific application and are pre-programmed to
perform certain specific tasks such as sea-floor
 Manned, mapping and imaging, temperature and salinity
 Remotely-operated, or measurement etc. Figure 1.2 shows the WHOI
 Autonomously-operated SEABED vehicle designed for optical and
acoustic sea-floor imagining. Upon completion
1.4.1 Manned Underwater Vehicles of the assigned tasks the vehicles typically
surface, broadcast their location (and often
A manned underwater vehicle is one that their captured data set) via satellite
contains a waterproof enclosure, pressurised to communications, and await recovery.
1 atmosphere, suitable for human occupation.
Examples include submarines for defence
purposes, and ALVIN, a scientific research
vehicle operated by the Woods Hole
Oceanographic Institution (WHOI) shown in
Figure 1.1.

Figure 1.2. SEABED, an autonomous survey vehicle,

operated by WHOI [3].

1.4.4 Typical ROV Configurations

Figure 1.1. ALVIN, a manned underwater vehicle, A typical commercial ROV will have some
operated by WHOI [2].
or all of the following attributes:
1.4.2 Remotely-Operated Underwater
 Surface-based operation
Vehicles
 Video cameras and lights for observation
A remotely-operated underwater vehicle is  Manipulators for environmental
controlled by an operator who remains out of intervention
the water. The operator typically uses a  Cables (commonly known as tethers) for
joystick to manipulate the position of the communication to and from the operator on
vehicle in the water, and a video display to see the surface, and power from the surface
the environment it is operating in.  Motors fitted with propellers for
propulsion and positioning (known as
This project focuses solely on this thrusters)
unmanned remotely-operated class of vehicle.  Sensors for depth and orientation, and
environmental monitoring

10
1.4.5 ROV Classification greater depths they operate at (typically down
to 1,000 m).
The commercial sub-sea industry applies
some broad categorisation to ROV’s. These 1.4.8 Light & Medium Work Class
can be summarised as:
A step up in size and durability of
 Micro Observational Class construction, these light-to-medium-weight
 Mini Observational Class ROV’s are typically fitted with a single small
 Light & Medium Work Class manipulator giving them a rudimentary ability
 Heavy Work Class to handle objects. Compared to the Heavy
 Seabed Working Class Work Class, they have relatively low thruster
power and therefore a lower payload lift
1.4.6 Micro Observational Class capacity. An example is shown in Figure 1.4.

These are typically light-weight

construction, optimised for portability,
designed exclusively for observation in
shallow waters (less than 100 m). Typical uses
include ship, pier and pipe inspections. Figure
1.3 shows an example from VideoRay LLC.

Figure 1.4. The Saab Seaeye Lynx is light-medium

work class ROV [5].

1.4.9 Heavy Work Class

Designed for extreme depths (up to 6,000 m

is not unusual), and situations where size and
weight are not considered primary
considerations, these heavy duty ROV’s
Figure 1.3. The P4 CD 300 is a micro observational perform the most challenging underwater
class ROV developed by VideoRay LLC [4].
tasks. They are usually fitted with at least two
manipulators, specialised tooling, multiple
1.4.7 Mini Observational Class cameras and lights, and as we have seen, pitch
and roll self-stabilisation systems. These
These vehicles perform a similar role to the vehicles can weigh in excess of 1.5 tonnes.
micro observational class vehicles but are Fitted with the most powerful thrusters
designed with heavier duty construction available, they can carry and lift the largest
techniques that make them more suited to the payloads, sometimes in excess of 300 kg.

11
Figure 1.5 shows an example from Saab 1.4.11 Commercial ROV Use
Seaeye.
As can be seen by the large variety of
ROV’s available, there are an accordingly
large number of applications they are used for.
Here is a selection:

 Port and pier inspection

 Trenching and ploughing
 Cable laying & maintenance
 Pipe laying & maintenance
 Nuclear plant inspection
 Water tank inspection
 Environmental monitoring
Figure 1.5. The Saab Seaeye Jaguar is a heavy work  Sea floor surveying
class ROV [6].  Wreck discovery
 Archaeology
1.4.10 Seabed Working Class  Acoustic positioning
 Harbour and coastal defence
These highly specialised vehicles are  Mine counter-measures
designed to lay undersea pipes and cables.  Sub-sea construction
Some are capable of cutting or blasting a  Well-head maintenance
channel in the seabed, laying the cable, and  Mining
then burying it, all in a single pass. An  Search-and-rescue
example from the Newcastle-based company
 Biological research
SMD Ltd is shown in Figure 1.6.
Major events where ROV’s have been used
extensively include:

 Japanese tsunami search-and-recue

 BP Macondo well-head repair
 The search for the Titanic
 The investigation into the sinking of the
Costa Concordia cruise ship

Figure 1.6. The SMD UT-1 jet trencher [7].

12
2. System Requirements and Working from these guidelines, the
following requirements were specified:
Architecture
 operator controller with joysticks,
From an analysis of commercial ROV’s
switches, status display screen and LED’s,
that can be found operating in the field, and
and video screen
with consideration to the ROV’s applications
and operating environments, the design of this  4 thrusters for horizontal positioning
ROV system has closely followed these  3 thrusters for vertical positioning and the
primary design guidelines: self-stabilisation system
 on-board power
 ease-of-use  30 m tether for data and video transfer
 portability between operator controller and ROV
 cost effective construction methods and  lightweight frame construction
materials
The system can be most easily visualised by
examining the major system blocks as shown
in Figure 2.1.

Vertical Left Vertical Rear Vertical Right

Joystick 1
Thruster Thruster Thruster

Horizontal
Joystick 2 Lights Front Right
Thruster

Horizontal
Temperature
Front Left
Sensor
Thruster

Horizontal
LCD Display Rear Right
Thruster
Top Controller Board Data 30m ethernet cable Bottom Controller Board

Horizontal
Buzzer Rear Left
Thruster

USB Video Temperature

LED’s
Sensor

Leak
Switches PC Detector
USB – development use only

Power Data
IMU
Supply Logging

Video
Camera

Power
Supply

Figure 2.1. ROV system block diagram.

13
3. Mechanical Design and which serves as a surface on which to mount
the trimming weights.
Construction
This Chapter details the many facets of
3.2 Frame Construction
designing and physically constructing an ROV.
The frame is constructed of plastic tubing,
and the associated connecting elements, with a
3.1 Frame Design nominal 32 mm outer diameter. This material
is lightweight yet rigid and strong, readily
The purpose of the frame is to support the
available, easy to work, and cost effective.
water-proof enclosure, the thruster motors, and
any trimming weights. Ideas for the frame
Images of the construction of the frame are
design were initially considered and assessed
shown in Figure 3.2.
using pencil and paper, and simple wire
models, as shown in Figure 3.1. The principle
design goal for the frame, taking into account
thruster and enclosure positioning and support,
was to ensure there was maximum water flow
through the open frame, to therefore minimise
drag.

Figure 3.1. Designing the frame.

The chosen design consists of 3 sections

placed horizontally perpendicular to the
forward direction of travel, two along the
bottom to support the enclosure, and a single
upper section towards the rear. They are used Figure 3.2. Construction of the frame.
for cross bracing and vertical thruster support,
and join the two rectangular side sub-frames All the wiring to and from the motors, and
that support the horizontal thrusters. the tether to the surface controller, have been
routed through the inside of the plastic tubing
The hollow frame is designed to fill with to minimise drag, to avoid damage to wiring,
water during operation to assist with buoyancy and to avoid fouling of the propellers.
and ballast trimming, and has a number of
holes drilled for this purpose. In addition, there
is a mesh attached to the bottom of the frame

14
 Figure 3.3. Routing and sealing the wiring.

After routing all the wires, they have been  the components are readily available
concentrated inside a box and connected to an through local suppliers
18-core cable using screw-terminals. This box  handy mounting hardware is available
was then flooded with a polyurethane resin to  they are easily machined for modifications
seal the connections from the water (Figure  they are purpose-designed for underground
3.3). installation so can handle external pressure,
at least to some degree
3.3 Water-Proof Enclosure Design and
Construction It should be noted that the components are
actually designed to keep water in, rather than
The water-proof enclosure is where all the water out, so it was initially unclear whether
underwater electronics and the video camera this system will prove to be completely water-
are located. Due to the high cost of these proof.
components, (approximately £300), keeping
water out of this area is absolutely essential, so In order to find out, a T-section with two
given the limited budget available, screw end-caps, and a single push-fit end-cap
considerable research was done into finding (as can be seen in Figure 3.2) were trialled in a
suitable low-cost off-the-shelf components that local swimming pool down to a maximum
would meet the requirements of: depth of 5 metres for 30 minutes. This testing
met with success as no water was detected
 water-proof inside the enclosure, so it was decided to
 accessible proceed with using these components.
 readily available
 usable 3.3.2 Adding a Window to the Water-
 modifiable Proof Enclosure
 uncompressible
Following the successful first test, the next
PVC drainage pipe fittings were found to fit step was to add a window for the video
these requirements as: camera. A number of designs were considered
for the window construction. Cross sections of
 they are designed with seals for blocking the various designs are shown in Figure 3.4
water with the red circles indicating the location of
 there are a range of fittings that will allow sealing o-rings.
access, via screw-thread and push-fit end-
caps

15
 Original 2
1

3 4 5

Figure 3.4. Cross-sections of designs for the camera window.

After some experimentation with the 3.3.3 Further Modification to the Water-
different options, it was found that using more Proof Enclosure
than a single o-ring did not allow the cap to be
screwed down enough to ensure a tight seal. It At this point confidence was high, but the
was also observed that if the o-ring was not biggest problem was yet to be faced. How to
held in place, the act of compression would get all the motor and signal wires through the
cause the o-ring to move and thus give an hull of the water-proof enclosure, and still keep
unreliable seal. For those reasons option 4 was the enclosure dry? With 2 wires for each of the
chosen. The window was then machined out 7 motors and 1 light, and 8 wires inside the
and installed as can be seen in Figure 3.5. Ethernet cable, this meant there are 24
individual wires. These 24 wires mean, in
Further water-proofing trials were then theory, there could be up to 24 individual holes
undertaken and they also proved to be a in the hull, and of course 24 holes = 24
success. possible leak sources.

After much consideration, the obvious

solution, though certainly not the cheapest
solution, but the one that was finally opted for,
was to concentrate all the wires into one single
multi-core cable with a single multi-pole
connector. This ensured there would be only a
single hull penetration, and therefore a much
reduced chance of leakage occurring.

By judiciously connecting all the common

12 V wires in the concentrating box, and
reducing the number of usable Ethernet wires
from 8 down to 6, the number of required
Figure 3.5. The camera window (with the protective connections was reduced to 18. An 18-core
masking still in place). cable was sourced, and a suitable IP68-rated
plug and socket acquired. Figure 3.6 shows the
construction of this cable and connectors
pairing.

16
 Figure 3.6. Construction of the 18-way cable and connectors.

Initial water-proof testing of the enclosure,  Machine away the white outer shell to
now fitted with the multi-pole connecter plug expose the sealed body and impeller.
followed and was thought to be successful.  Remove the impeller
Subsequent operation showed this was not the  Attach a propeller-to-shaft adapter to the
case, and small amounts of water motor shaft
(approximately 4 tablespoons per hour were  Attach a propeller to the adapter
observed) were entering the enclosure through  Repeat six more times
the hole that was created for the connector.

Upon inspection, it became obvious that the

hole had not been made sufficiently accurately
and did not meet the connector manufacturers’
specifications. An additional end-cap was
purchased and another hole was machined, this
time much more accurately using more
appropriate and accurate tools.

3.4 Propulsion by Thrusters

Propulsion of the vehicle through the water,

both vertically and horizontally, under control
of the operator, is the job of the thrusters.

3.4.1 Thruster Construction

The thrusters used for this project are sealed

DC motors, derived from bilge pumps, and
fitted with propellers. Figure 3.7 shows the
pumps before, during and after modification.
To turn the bilge pumps into ROV thrusters,
the following steps were undertaken:

 Unclip the blue protective shroud

Figure 3.7. Conversion from bilge pump to thruster.

17
3.4.2 Horizontal Thruster Configuration use the vectored layout, as does the SMD UT-1
(Figure 1.6).
An analysis of the commercial ROV market
shows two common configurations are used for The H layout requires only three thrusters
horizontal thruster placement: instead of four which gives a small cost
advantage, but there are also a number of
 the “H” layout as shown in Figure 3.8 disadvantages:
 the “vectored” layout as shown in Figure
3.9  All three thrusters require bi-directional
control (i.e. they must be able to be driven
forward or backward), which incurs
significant additional cost and complexity
in the control electronics
 6 wires have to be passed through the
water-proof pressure hull
 Sideways motion is relatively slow as there
is only a single thruster
 The single sideways-acting thruster should
be mounted exactly at the centroid of the
ROV otherwise it will impart a rotational
force on the ROV

The vectored layout on the other hand

requires only uni-directional thruster control,
Figure 3.8. “H” horizontal thruster layout. giving simpler, cheaper electronics, and needs
only 5 connections through the hull (as one
wire is common to all thrusters and can be
connected together externally). The major
disadvantage of this layout is that the
maximum thrust for forward, reverse and
sideways operations is reduced by 30% due to
the 45 offset of each thruster from the
direction of travel.

Clearly, both layouts offer unique

advantages and disadvantages, but after careful
consideration of these, the vectored layout was
chosen. The thrust reduction due to the angled
thruster mounting was deemed to be an
acceptable trade-off for simpler electronics.
Figure 3.9. “Vectored” horizontal thruster layout.
Figure 3.10 shows how, using the vectored
Both configurations are used commercially: layout, a combination of any two thrusters
the P4 CD 300 from VideoRay LLC, (Figure gives 6 possible directions of movement.
1.3) uses the H layout, whereas the Saab
Seaeye Lynx and Jaguar, (Figures 1.4 and 1.5),

18
 Figure 3.10. Directional control using a “vectored” horizontal thruster layout.

3.4.3 Vertical Thruster Configuration frames at the midpoint. These thrusters are set
at an angle offset from the vertical to assist in
For simple vertical positioning control, a roll correction. For normal vertical positioning
single bi-directional thruster, centrally located, they are driven equally, but for roll correction
and mounted vertically is sufficient. However, they are driven at different rates, and different
to support the self-stabilisation system (see directions if necessary.
Chapter 6), additional bi-directional thrusters
are necessary to give the ability to correct For the pitch axis, a single thruster is
disturbances along the pitch and roll axes. mounted at the top rear of the frame. The offset
to the vertical is one of the factors considered
For the roll axis correction, a thruster is during the testing phase and discussed in
mounted along the top of the left and right side Chapter 7. It is not used for normal vertical

19
positioning of the ROV as its non-symmetric
positioning on the frame may induce pitch.

3.4.4 Propellers

A number of different propellers (Figure

3.11) have been tested to ascertain the relative
thrust measurements and the current draw by
the thruster motors, to find the most suitable
propeller:

 Unmodified bilge pump with impeller

 Robbe R1473 3-blade 35 mm propeller
 Robbe R1471 3-blade 50 mm propeller Figure 3.12. Thrust and current draw measurements.
 Robbe R1465 3-blade 60 mm propeller
 Graupner G2308.50 3-blade 50 mm
propeller Current
Thrust
 Graupner G2298.40 5-blade 40 mm Propeller Draw
(g)
g/A
propeller (A)
Bilge
pump 1.60 75 46.88
impeller
3-blade
Robbe 35 2.05 125 60.98
mm
3-blade
Robbe 50 2.80 190 67.86
mm
3-blade
Robbe 60 3.50 190 54.29
mm
3-blade
Graupner 2.20 250 113.64
50 mm
Figure 3.11. Five different propellers were tested. 5-blade
Graupner 2.10 170 80.95
40 mm
The testing apparatus is shown in Figure
Table 3.1. Thrust and current draw measurement
3.12 and consists of a rotating cross-shaped results.
structure with the thruster attached to one end.
When power is applied to the thruster, the On a gram per Amp basis, the Graupner 50
structure pivots and applies a downward force mm propeller seems the logical choice,
to the scales. That force, measured as weight however it was noted during testing that the 5-
by the scales, is directly proportional to the bladed 40 mm Graupner propeller generated
thruster force output. Due to the nature of the significantly less turbulence. It also had a
testing apparatus, the measurements taken are much higher reverse thrust compared to any of
not considered highly accurate but serve to the 3-blade propellers. Minimising turbulence
provide relative indications of the differences is important for good visibility during
between the propellers. The results, averaged operation of the ROV and though reverse
over a number of tests, are shown in Table 3.1. thrust is not important for the horizontal
thrusters, it is critical for the vertical thrusters.
For these reasons, 5-blade 40 mm Graupner
propellers were chosen for all seven thrusters.

20
3.4.5 Propeller Rotation

As a single propeller rotates, it imparts a

rotational force to the vehicle, and this has the
effect of steering the vehicle to the right or left.
To minimise this force, two thrusters are used
simultaneously, with each thruster having a
propeller that rotates in the opposite direction
to the other. Table 3.2 shows the allocation of
rotation direction to the individual thrusters.

Rotation
Thruster
Direction
Figure 3.14. Clockwise rotating propeller.
Horizontal Counter-
Front Right Clockwise
3.5 Tether
Horizontal
Clockwise
Front Left
The tether is the physical and
Horizontal communications link between the top
Clockwise
Rear Right controller, located out of the water, and the
Horizontal Counter- ROV in the water. It has 3 responsibilities:
Rear Left Clockwise
Vertical Counter-  deliver instructions down to the ROV from
Right Clockwise the top controller
Vertical  deliver sensor data from the ROV up to the
Clockwise
Left top controller
Vertical Counter-
 deliver video up to the operator
Rear Clockwise
The tether in this case consists of a single
Table 3.2. Thruster propeller rotation direction.
30 m Ethernet cable (Cat. 6), with two of the
To ensure an equivalent level of thrust from four sets of twisted pairs being used. This
each of the two thrusters, propellers designed length will give a maximum depth of 30 metres
for opposite rotation are used. Figures 3.13 and straight down, and 21 metres out at a 45
3.14 show the two different 5-bladed angle. 30 metres is the typical maximum depth
propellers used, each designed for rotation in a of recreational scuba divers, and therefore the
specific direction. maximum depth for easily testing the ROV,
allowing for an emergency recovery.

Two wires (one set of the four twisted pairs,

wires 1 and 2) are used for serial
communications between the top controller
and bottom controller. A third wire (wire 3) is
used to carry the analogue video signal, and a
fourth wire (wire 4) is the common ground
connection between the top and bottom
controllers. A third pair (wires 5 and 6) are
unused, but available for future use. The fourth
pair (wires 7 and 8) are not connected at all
due to the lack of spare conductors in the 18-
core cable running into the water-proof
Figure 3.13. Counter-clockwise rotating propeller. enclosure.

The primary physical requirements for the

tether are that it must be as light and small as

21
possible to minimise drag through the water,
and ideally should be neutrally buoyant. The The bandwidth available with long range
ethernet cable is not neutrally buoyant so a acoustic modems is approximately 10 kbps [8].
number of floatation devices are attached to This would be sufficient for control and sensor
the tether at regular intervals to ensure neutral data but is not sufficient for video transmission
buoyancy. To avoid fouling of the tether with and therefore makes it unsuitable for this
the thrusters, the tether is made positively project. There are considerable efforts
buoyant for the metre closest to the ROV. currently underway to apply modern
communications techniques such as OFDM
For physical protection, at the ROV end a and MIMO to underwater communications [9],
cable strain relief grommet is used, and the so this may be less of an issue going forward.
first 5 metres of the tether are enclosed in a
black braided sheath. The second problem is that sound
propagates through water at approximately
3.5.1 Wireless Communications 1,500 metres per second [10] which is vastly
slower than an electrical signal in a cable that
It has been suggested that a completely travels at close to the speed of light. Therefore
wireless system may be possible and this has a considerable level of latency occurs and this
been investigated but despite being a very obviously increases as the distance increases.
interesting subject has been found unsuitable This may not be a significant factor for a
for this specific project. Briefly, there are a distance of 30 metres, but for commercial
number of advantages to a wireless system ROV’s operating in real-time at 6,000 metres it
including: is an unworkable solution as round trip times
would be in the order of 8 seconds.
 less drag
 fewer buoyancy issues The examination of the propagation of
 no tangles, snags or propeller fouling sound through water, sea water in particular, is
not a trivial exercise and well outside the scope
There are however, two major technical of this project. The reader is encouraged to
problems with underwater wireless look at the US Navy publication “Physics of
communications: Sound in the Sea” resulting from research done
during World War II for further details on the
 limited bandwidth physics of communications through sea water.
 latency

22
4. Top Controller  a temperature sensor
 a buzzer
The primary purpose of the top controller is  the serial connection to the bottom
to act as the operator control interface. From controller
the operator’s point-of-view, they need to be
able to control the position of the ROV in the The circuit diagram and strip-board layout
water on any one of four axes, as easily as can be found in Appendix B, and the final
possible, and receive timely feedback from the operational microcontroller C programming
ROV of its position and the nature of the code in Appendix D.
environment it is in.
4.2 Construction and Testing

For a system as complex as the top

controller, where almost every available I/O
pin is being used on the mbed microcontroller,
connecting every element simultaneously and
then attempting to test and debugging from
there, from experience, seemed likely to be
inefficient and ineffective.

Instead, an alternative and ultimately

successful approach was used, where each
element of the top controller was first tested in
isolation from the other elements of the system
to ensure they performed as required (see
Figure 4.1. The completed top controller.
Figure 4.2). Only once they were proven to
work in isolation were they integrated into the
The following sections of this Chapter detail evolving system built on a breadboard. As each
the design, specification and construction of new element was added, it along with all the
the operator control interface. existing elements already in place, were then
fully tested to ensure they worked with each
4.1 Top Controller Design other.

From the requirements it was determined

that the 4-degree-of-freedom (DOF)
positioning and control performed by the
operator (forward/backwards, up/down, move
left/move right, and rotate left/rotate right)
would be best achieved using two joysticks
and a number of switches. Feedback to the
operator would come via a video screen, an
LCD screen for sensor data and warnings, and
a number of LED’s to indicate a particular
state or warning.

The electronic design of the top controller Figure 4.2. Two mbed modules mounted on a
centres around a microcontroller (in this case breadboard during serial communications testing.
an NXP LPC1768 on an mbed microcontroller
development board) interfaced to: This gradual addition, element by element,
to the working system, ensured that any
 three switches problems that did occur were easily identified.
 an LCD screen Figure 4.3 shows the development in progress.
 two joysticks
 six LED’s

23
 The order of implementation was: Two primary tools were used during the
testing and construction phase. Firstly, a digital
1. mbed microcontroller development board multi-meter was used for checking connections
2. voltage regulator and voltage levels to ensure every component
3. LCD display was correctly placed and wired. The second
4. joysticks tool was the LCD display which proved to be
5. temperature sensor very useful. It was used extensively during the
6. leak buzzer development of the top controller (and also the
7. switches bottom controller) due to the flexible nature of
8. LED’s the data it can display. This is primarily due to
9. RS232 the ease-of-use offered by the mbed rapid
prototyping development system.
Only once the top controller was working
entirely as required on the breadboard, was it 4.3 mbed Rapid Prototyping
moved onto the strip-board, as shown in Figure Development System
4.3.
The mbed development system is the
combination of an NXP LPC1768
microcontroller mounted on a user-friendly
0.1”-spaced DIP package, an online web-based
development environment, and a collection of
official and community-developed standard
libraries. This combination is specifically
designed to facilitate quick and easy
prototyping as can be seen in Figure 4.2.

The NXP microcontroller has an ARM

Cortex-M3-based core running at 96 MHz It
contains 512 kB of flash memory, 32 kB RAM
along with I2C, SPI, CAN and serial I/O, 6
PWM output channels, 6 ADC input channels,
and a single DAC output channel. It also offers
USB and Ethernet connectivity and a 3.3V
regulated power output [11].

4.4 Power Supply

Operation of the top controller requires a

number of different voltage levels. The mbed
microcontroller can accept an input from 4.5 V
to 14.0 V, the LCD display operates logically
at 3.3 V, though its backlight requires 4.2 V,
and the RS232 IC requires 3.3 V for operation.

Power was supplied during development by a

standard PP3 9 V battery. A 5 V linear voltage
regulator, TS7805CZ, is used to cut the 9 V
down to 5 V for both the LCD backlight and
the mbed. The 4.2 V for the backlight is
generated from the 5 V using a voltage divider
circuit.
Figure 4.3. The top controller during development, on
breadboard (top) and later on strip-board (bottom).

24
 The 3.3 V required by the LCD display and each axis of each joystick is connected to an
RS232 IC is generated by the mbed’s onboard ADC input on the mbed microcontroller where
voltage regulator. the value of the resistance in the
potentiometers, and therefore the position of
4.5 LCD Display the joystick, is directly proportional to the
voltage appearing at the ADC input, referenced
The LCD display chosen is a 20 x 4 to 3.3 V.
character black-on-green display fitted with an
LED backlight. The display uses a 4-bit Though the joysticks are analog devices,
parallel data connection to the microcontroller they are effectively used as digital inputs with
(there is also the option to use an 8-bit one of six possible states:
connection) and requires 2 additional control
lines: ‘RS’ and ‘E’ [12]. It is powered from the  up
3.3 V generated by the mbed’s onboard  down
regulator. The backlight is powered separately  left
by a 4.2 V source.  right
 horizontally centred
During ROV operation, the display is used  vertically centred
to indicate some or all of:
The software determines the current state of
 the state of the joysticks each joystick based on the value returned from
 the temperatures from the sensors in the the ADC input, and maps that to the
top and bottom controllers appropriate instruction for the ROV.
 the pitch and roll tilt angles
 the PID control settings The sampling of the joysticks occurs 20
 the status of the data logging function, the times per second. Subjective testing indicated
lights and the control system an update rate any slower induced a
 leak warnings perceptible lag between the operator input and
 H-bridge over-temperature warning the ROV response.

4.6 Analog Joysticks 4.7 Temperature Sensor

The top controller uses two analog joysticks The top controller is fitted with a
to allow the operator to control the position of temperature sensor to measure the temperature
the ROV in the water along any of 4 different inside the enclosure. This information is
axes. Figure 4.4 shows how the eight possible sampled every few seconds and displayed on
position instructions are mapped to the eight the LCD display.
joystick positions.
The sensor is an LM335 from National
Semiconductor, supplied in an easy-to-use
Raise Forward
plastic TO-92 package. It was chosen as it
offers a good balance between price and
accuracy. It has an operating range from -40
Move Move Turn Turn to +100 C and is typically accurate to ±2 C
Left Right Left Right
which was considered acceptable for this
application, however accuracy can be
Lower Reverse increased by calibration if necessary.
Left Joystick Right Joystick
The sensor works like a Zener diode with a
Figure 4.4. Joystick control direction assignment.
breakdown voltage output directly proportional
to the temperature at 10 mV / K [13]. Due to
Each joystick is essentially a structure the linearity of its output, by connecting to an
holding two linear potentiometers aligned ADC input on the microcontroller, the ambient
along two perpendicular axes. The output from temperature in degrees Celsius can be

25
calculated using the following formula, where
the sampled value is in the range of [0, 1]: Tables 4.1, 4.2 and 4.3 detail the 14 bytes
sent from the top controller to the bottom
controller:
(1)
Byte Name Purpose
8 bits for
4.8 Water Leak Detection Warnings 1 controlData[0]
control data
8 bits for
If the bottom controller detects a water leak 2 controlData[1]
control data
into the water-proof enclosure, it will first byte of 4
communicate this to the top controller. The top 3 kP8[0]
for kP float
controller will respond to this by sounding a second “
small buzzer, displaying a warning on the LCD 4 kP8[1]
“
screen, and illuminating a red LED. third “
5 kP8[2]
“
4.9 Switches and LED’s fourth “
6 kP8[3]
“
The top controller has 3 switches and 6 first byte of 4
status LED’s. The three switches are used for: 7 kI8[0]
for kI float
second “
 lights on / off 8 kI8[1]
“
 control system on / off third “
 data logging on / off 9 kI8[2]
“
fourth “
The LED’s are used for: 10 kI8[3]
“
first byte of 4
 power (green) 11 kD8[0]
for kD float
 leak detected (red) second “
 12 kD8[1]
data link to bottom controller (green) “
 state of light switch (green) third “
 13 kD8[2]
state of control system switch (green) “
 state of data logging switch (green) fourth “
14 kD8[3]
“
4.10 Data Communications
Table 4.1. Data sent from the top controller to the
bottom controller.
The top controller has two separate data
communications channels.
Bit Number Purpose
4.10.1 Communication with the Bottom 7 ‘1’ = first control data byte
Controller 6 ‘1’ = data logging on
5 ‘1’ = control system on
Communications between the top controller
4 ‘1’ = lights on
and bottom controller, via the tether, are by
3 ‘1’ = rear left thruster on
RS232 serial. An EXAR SP3232ECP-L driver
chip is used in both controllers for this as the 2 ‘1’ = rear right thruster on
inbuilt serial UART’s in the mbed 1 ‘1’ = front left thruster on
microcontroller are not designed for 0 ‘1’ = front right thruster on
transmitting over 30 m cable lengths.
Table 4.2. controlData[0] byte.

A relatively simple communications

protocol was established for the exchange of
control and sensor data between the top and
bottom controllers.

26
 Bit Number Purpose 4.10.2 Communications with the
7 ‘0’ = second control data byte Development PC
6 unused
5 unused The mbed development board includes a
4 unused USB connection to the development PC. This
3 unused connection was used, in addition to
2 unused downloading program code, to give a serial
1 ‘1’ = drive down terminal interface to the top controller and to
0 ‘1’ = drive up the bottom controller, via the top controller.
This serial terminal interface was used for
Table 4.3. controlData[1] byte. debugging purposes, and for PID control
tuning on-the-fly.

Transmission of floating point values for Figure 4.5 shows a terminal session in
the P, I, and D constants for the control system operation during development, between the
is achieved by breaking the 32-bit floating development PC and the top controller.
point value into four 8-bit values and sending
those, as shown in Table 4.1. Each set of four
bytes is then reconstructed back into a 32-bit
floating point value at the receiving end by the
bottom controller.

There are also 4 bytes sent back from the

bottom controller to the top controller:

Byte Name Purpose

1 txData[0] 8 bits for warning flags
2 txData[1] bottom temperature
3 txData[2] pitch tilt angle
4 txData[3] roll tilt angle Figure 4.5. Serial terminal interface, via USB, from
the development PC to the top controller.
Table 4.4. Data sent from the bottom controller to the
top controller.
4.11 Enclosure Design

Bit Number Purpose The front panel design, to fit the chosen
7 ‘1’ = first data byte enclosure, is shown in Figure 4.6.
6 unused
5 ‘1’ = thermal overload Power Lights
detected
4 ‘1’ = thermal overload Leak Control
System
detected
3 ‘1’ = thermal overload Link Data
Logging

detected
2 ‘1’ = leak detected
1 ‘1’ = leak detected
0 ‘1’ = leak detected

Table 4.5. txData[0] byte.

Figure 4.6. Front panel design.

27
The rear of the enclosure is where the tether timer function that generates interrupts. These
input and video output connections are made. tasks include:
This is shown in Figure 4.7.
 read the temperature sensor once every 3
seconds
 read the joystick positions 20 times per
TETHER VIDEO second i.e. every 0.05 seconds
OUT
 update the LCD display 20 times per
second
 send and receive data to and from the
bottom controller 20 times per second

Figure 4.7. Rear panel design. In addition, asynchronous changes by the

operator of any of the three switches on the
control panel are also handled by the interrupt
4.12 Software mechanism.

The design of the top controller software Figure 4.8 shows a representation of the
running on the ARM microcontroller follows system.
an “interrupt-driven” model. Periodic tasks
were set up to run at regular intervals using a

Initialisation

3 second timer: Wait for interrupt or timer Interrupt on switch state

- read temperature sensor event change

0.05 second timer:

- read joysticks
- update LCD
- RX/TX with bottom

Figure 4.8. Top controller system block diagram.

28
5. Bottom Controller  an IMU daughterboard
 a temperature sensor
The primary purpose of the bottom  a leak detector
controller is operation of the thrusters and  the serial connection to the top controller
lights, as instructed by the operator using the
top controller. There are 7 thrusters: 4 The circuit diagram and strip-board layout
requiring uni-directional control, and 3 can be found in Appendix C, and the
requiring bi-directional control. There is also microcontroller C programming code in
an integrated inertial measurement unit (IMU) Appendix E.
for the self-stabilising control system.
5.2 Construction and Testing

As occurred for the top controller, the

bottom controller system uses almost every
available I/O pin on the mbed microcontroller,
so testing by connecting every element
simultaneously and debugging from there,
once again seemed likely to be an inefficient
and ineffective approach.

The alternative and ultimately successful

approach was used again, where each element
of the bottom controller was first tested in
isolation from the other elements of the system
Figure 5.1. The completed bottom controller. to ensure they performed as required. Only
once they were proven to work in isolation
The following sections of this Chapter were they integrated into the evolving system
detail the design, specification and built on a breadboard. As each new element
construction of the bottom controller. was added, it along with all the existing
elements already in place, were then fully
5.1 Bottom Controller Design tested to ensure they worked with each other.

Given the requirements of supporting four This gradual addition, element by element,
uni-directional, and three bi-directional to the working system, ensured that any
thrusters, and one light switch, it was problems that did occur were easily identified.
determined that five MOSFET’s, acting as Figure 5.2 shows the development in progress.
switches, and three H-bridge motor drive IC’s The order of implementation for the bottom
would be required. In addition a range of controller was:
sensors would be required:
1. mbed microcontroller development board
 a 2-axis tilt sensor for the control system 2. IMU
 a leak detector 3. Leak detector
4. temperature sensor
 a video camera to allow the operator to see
5. voltage regulator
where the ROV was heading
6. MOSFET’s
 a temperature sensor
7. H-Bridges
8. RS232
The electronic design of the bottom
9. Data logging
controller centres around a microcontroller
10. Lights
(once again an NXP LPC1768 on an mbed
11. Camera
microcontroller development board) interfaced
to:

 five MOSFET’s
 three H-bridge IC’s

29
 conversion from floating point value to degrees
is found by:

(2)

During development of the control system,

certain spurious values were noticed to be
coming from the accelerometer. An analysis
and resolution of this issue can be found in
Appendix I.
Figure 5.2. The bottom controller during
development, on breadboard, wired to the seven
thrusters. The IMU board also conveniently contains
a micro SD slot connected through to the
Again, only once the entire bottom mbed. This was used for the data-logging and
controller was working reliably on the is described in section 5.13. The schematic
breadboard, was it moved onto the strip-board and PCB layout of the IMU board as designed
(see figure 5.1). by Tim Marvin can also be found in Appendix
G.
5.3 mbed Rapid Prototyping
Development System 5.5 Leak Detector

The same mbed development system as To warn of any leaks that may have
used in the top controller is once again the occurred inside the water-proof enclosure, a
central core of the bottom controller system. leak detector system has been developed. As
Three of the six available PWM output can be seen in Figure 5.3, it consists of a small
channels are used to drive, at variable speed section of copper-coated strip-board with the
and direction, the H-bridges for the vertical connecting wires attached to adjoining tracks.
thrusters that require bidirectional control.

5.4 Inertial Measurement Unit

A 2-axis accelerometer is used to perform

the tilt measurements for the roll and pitch
axes used with the self-stabilising control
system. The accelerometer used in this project,
an LIS331DLH from ST Microelectronics, is
part of a complete inertial measurement unit
(IMU) that was designed by Tim Marvin
specifically to work with the mbed
development board. As can be seen in Figure
5.1, it has been cleverly designed so that the
mbed board plugs in to the top.
Figure 5.3. The leak detectors.
Originally designed for a model aircraft
autopilot system, it contains, in addition to the
2 accelerometer axes used, a third If any water is present and causes a bridge
accelerometer axis, a 3-axis gyroscope, and a across the copper tracks, a positive voltage
3-axis magnetometer. appears on pin 11 of the mbed. The software is
configured to react to this pin going high and
Each axis of the accelerometer outputs a transmits a warning signal to the top controller,
floating point value in the range of -1 to +1 where an LED is lit, a buzzer sounds and a
corresponding to -90 to +90 [14]. The message appears on the LCD display.

30
5.6 Temperature Sensor 5.7.2 On-Board Power

Like the top controller, the bottom A number of factors were considered when
controller is also fitted with an LM335 looking at the different onboard power source
temperature sensor to measure the temperature options:
inside the water-proof enclosure. This
information is sampled every few seconds and  cost
communicated to the top controller for display  recharge ability
on the LCD display.  size and weight
 voltage
5.7 Power Supply  power capacity and energy density

Two methods of supplying power to the Given those factors, a number are different
bottom controller were considered: battery technologies were investigated:

 Power from the surface, via the tether  Lead acid

 Power from batteries on board the ROV  Nickel Cadmium
 Nickel Metal Hydride
5.7.1 Power from the Surface  Lithium Polymer

Powering the ROV from the surface was Lead acid batteries, as used in automotives,
initially investigated, but a major problem were deemed too heavy, too big, and prone to
using the surface power option became evident leakage. Nickel Cadmium and Nickel Metal
quickly: the voltage drop along the wire caused Hydride batteries were also looked at closely
by the inherent resistance of the wire. It can be but the decision was made to use the Lithium
overcome to some degree by using a larger Polymer (LIPO) batteries as they offered:
gauge wire but this adds weight to the tether
and therefore increases drag and buoyancy  greatest power-to-weight ratio and energy
requirements. Furthermore, as the current density
drawn through the wire will vary depending  ready availability in large capacity
upon which motors are being used, so does the configurations
voltage drop vary, giving an unpredictable  suitable cell voltage
voltage at the ROV end of the tether. A simple
 suitable form-factor
example is illustrated in Table 5.1:
 lowest self-discharge rate when not used
 reasonable cost
Surface Current Voltage Available
Voltage Draw Drop Voltage  no memory effect
12 V 1 Amp 0.425 V 11.575 V
12 V 3 Amps 1.276 V 10.724 V The specific LIPO battery used during
development is the Turnigy 2.2 Ah 3S 30C
12 V 6 Amps 2.552 V 9.448 V
battery (see Figure 5.4) that offers a nominal
Table 5.1. Voltage drop example. 11.1 V (3 cells @ 3.7 V, each in series). In
practice it can be charged up to 12.6 V and is
These calculations are based on a 30 m generally considered to have only 10%
length of 2.5 mm2 copper conductor. capacity remaining at 11.1 V.

As the H-bridges used (see section 5.9)

have a low voltage cut-out somewhere in the
range of 9 V to 11 V, just the possibility of the
voltage dropping down into this range
suggested this was not the optimal solution, so
the alternative of an on-board power source
was investigated.
Figure 5.4. Turnigy 2.2 Ah 3S 30C LIPO battery.

31
 The “30C” rating of the battery indicates The major factors considered when
the maximum continuous discharge current the selecting the MOSFET were:
battery can deliver without overheating and
damaging the battery:  cost
 availability
(3)  usability
 suitability

Based on these factors, the RFP30N06LE

was chosen as it was readily available from a
From this it can be seen that the 30C rating
trusted supplier, costs only £0.89, was suitable
for this 2.2 Ah battery is more than suitable for
for through-hole construction, had a voltage
the ROV bottom controller system which does
and current capacity of 60 V and 30A and was
not draw much more than 5 - 6 Amps at any
compatible with the 3.3 V operation of the
time.
microcontroller [15].
It is estimated that this single LIPO battery
To use these devices as simple logical
will give a typical run-time of around 15
switches, it was found necessary to add a 10
minutes. This can easily be extended by simply
K resistor from the gate to ground, as
adding more batteries in parallel.
without the resistor the MOSFET would not
turn off due to the device capacitance. With the
LIPO batteries are not without their
resistor fitted, the capacitance now has a path
limitations though and need to be carefully
to dissipate and the device turns off.
handled. The first battery used was destroyed
by accidently shorting the positive and
negative terminals when attaching a connector, 5.9 H-Bridges
and a second destroyed by inadvertently not
disconnecting it after use and letting it The three vertical thrusters, operating at or
discharge too low: if the cells are discharged around 12 V, require bi-directional variable
below 9 V they cannot be recharged. They are speed control to enable the ROV to ascend and
also prone to exploding if punctured or descend. For this reason, a simple MOSFET
charged incorrectly, and a special LIPO acting as an on / off switch will not work. A
“balancing” charger must be used to ensure configuration of switching relays could be used
each of the three internal cells is charged at to change direction, but they do not switch fast
and to the same voltage, without over- enough to be used with a pulse-width-
charging. modulated variable-speed system (see section
5.9.1).
The motors and lights are driven directly
off the LIPO’s nominal 11.1 V supply. A 5 V The solution is to use a circuit arrangement
linear voltage regulator, TS7805CZ, is used to known as an H-bridge as they allow for high-
reduce the 12 V down to 5V for the mbed. The speed-switching bidirectional motor control.
3.3 V required by the other logic devices and An H-bridge can be built from discrete
the RS232 IC is generated by the mbed’s components but many IC versions are readily
onboard voltage regulator. available so it was decided to use one of these,
if a suitable one could be found.
5.8 MOSFET’s
Once again, the major factors considered
when selecting an H-bridge IC were:
The lights, and the four uni-directional
horizontal thrusters, operating at 12 V, are
simply switched on or off as required by the  cost
microcontroller. Unfortunately the  availability
microcontroller cannot handle the 12 V  usability
switching task and so a MOSFET is employed  suitability
as a switch.

32
 Unfortunately the choice is not as easy as
when choosing a MOSFET: most modern H-
bridge motor drive IC’s are only supplied in
surface mount format which is not compatible
with the through-hole construction techniques
used in this project. This greatly limits the
choice of components available but there is
one component found that meets some of the
criteria: the LMD18200 from National
Semiconductor (now a part of Texas
Instruments).
Figure 5.5. Three LMD18200 H-bridge IC’s mounted
The chip is readily available, and is suitable on their break-out boards.
for the application, being able to deliver up to
3 A continuously [16]. It is supplied in a 5.9.1 Pulse Width Modulation
cumbersome 11 pin dual inline TO-220
package with an awkward pin spacing of 0.67” Pulse Width Modulation (PWM) is a
but fortunately a break-out board to convert to method commonly used for digital control of
the more common 0.1” pin spacing is certain analogue devices such as DC motors
available. The major issue with this IC is the and LED lights. It involves sending a pulse
cost: £18.40 each (plus £1.28 for the breakout train of high and low levels, at varying ratios
board). Figure 5.5 shows the three (the duty cycle), to effectively mimic a varying
LMD18200’s mounted on their breakout voltage level. A digital PWM system offers a
boards, and installed on the strip-board. The very flexible and fine-grained control of the
chip has a number of connections: speed of a motor by being able to control
programmatically the time of the high level
Pin Connected output compared to the low level output.
Use
Number To
1 no connection -
motor connection Clock
2 motor +
+ 20%
3 mbed pin 18 motor direction
40%
not used, tied to
4 brake 60%
ground
5 mbed pin 21 motor PWM 80%
6 12 V power supply
7 ground circuit ground
8 current sense not used Figure 5.6. PWM duty cycle operation.
thermal overload
9 mbed pin As can be seen in Figure 5.6, when there is
detection
motor connection a high level 20% of the time, and a low level
10 motor - 80% of the time (i.e. a 20% duty cycle), the
-
11 no connection - effective average voltage over the total period
is 20% of the maximum output voltage. If that
Table 5.2. LMD18200 pin assignment. maximum output voltage is 12 V, then: 20% of
12 V = 2.40 V. Accordingly, when there is a
As per the recommendation of National high level 80% of the time, and a low level
Semiconductor, 300 F bypass capacitance 20% of the time, the effective average voltage
was used to absorb any back EMF caused by over the total period is 80% of 12 V = 9.60 V.
switching the inductive load, and a heatsink Therefore by varying the ratio of high-level
was attached. time to low-level time, many different average
voltage values can be obtained between 0 V
and 12 V.

33
 The total time period for each PWM cycle, water-proof housing, and minimise external
and therefore the switching frequency, can be wiring junctions.
varied according to the components used. It is
common for DC motor PWM operation to The camera chosen, as can be seen mounted
have an operating frequency at a level outside on the front of the bottom controller in Figure
the range of human hearing, though that is not 5.1, is the colour CM-26N/P CMOS board
of concern when the motors are submerged. A video camera. It is powered from the 5 V
period of 100 microseconds, giving an supply of the bottom controller. The video
operating frequency of 10 kHz was found to be signal output is analogue TV quality (PAL or
perfectly acceptable. NTSC) via a 2-wire composite format (signal
and ground) [17].
5.10 Data Communications
The video signal is transmitted to the
The bottom controller has two separate data operator via one of the wires inside the
communications channels. Ethernet cable. It is then available as output
from the top controller for connection to a tv,
5.10.1 Communication with the Top monitor or PC fitted with suitable analog video
Controller capture capabilities.

Communications between the top controller Despite operating perfectly well for a few
and bottom controller, via the tether, are by months during testing, in February the camera
RS232 serial. An EXAR SP3232ECP-L driver module developed a fault and has been
chip is used in both controllers for this. returned to the supplier for replacement.
Unfortunately the replacement has not yet been
5.10.2 Communications with the received as they are currently out of stock.
Development PC
5.12 Lights
The mbed development board includes a
USB connection to the development PC. This As the development and testing of the ROV
connection was used, in addition to has been conducted in relatively shallow
downloading program code, to give a serial (maximum depth 5 metres) suburban
terminal interface direct to the bottom swimming pools, the development of the lights
controller for debugging purposes. has not been absolutely necessary, and has
currently not progressed beyond some basic
investigations into driving and mounting
5.11 Video Camera
LED’s.
A number of considerations were made
when examining the options for generating the
video image sent up the tether to the operator:

 cost
 ease of application
 image type and quality

Very expensive diving cameras, in very

expensive water-proof housings, are readily
available but the aim was to keep the cost of
the video camera to a minimum. The solution
was to find a small camera that would operate
from within the existing water-proof enclosure
(with the obvious addition of a window). This
Figure 5.7. LED light experiment.
would allow the use of the existing power
supply, remove the need for an additional
Figure 5.7 shows an example of three white
LED’s connected in series and “mounted” to a

34
heatsink that was at hand at the time. (Figure 5.8) was donated to the project, but it
Considerable further work is necessary here on has not yet been fitted to the ROV. It operates
mounting, driving, and ultimately sealing the on the principle of an increased output voltage
lights, and it may end up simply easier to proportional to the pressure on the outer
purchase pre-made submersible lights. For the diaphragm [18].
short term, a diving torch is available if
required.

Full support for the addition of lights has

been made in the bottom controller circuitry,
control software, top controller switch, and
ROV wiring, and the lights simply need to be
connected to the in-place wiring and physically
mounted to the ROV frame.

5.13 Data Logger

The IMU daughterboard used for this

project conveniently includes a micro SD card Figure 5.8. Keller PAA-6L pressure transducer.
slot and this is used for logging data as
required.
5.15 Software
A typical sample of the data obtained
during one of the data logging exercises is
The design of the bottom controller
shown in Table 5.3.
software running on the ARM microcontroller
follows a modified “interrupt-driven” model.
Time Pitch VB motor
PitchAdj Periodic tasks have been set up to run at
stamp angle power
1.034826 0.031372 -0.015686 0.007500 regular intervals using a timer function that
1.176539 0.015686 -0.007843 0.015417 generates interrupts. These tasks include:
1.234058 0.015686 -0.007843 0.007500
1.291520 0.015686 -0.007843 0.007500
 read the temperature sensor once every 3
1.349056 0.015686 -0.007843 0.007500
1.480808 0.015686 -0.007843 0.007500 seconds
 read the tilt sensors 4 times per second ie
Table 5.3. Example of logged data. every 0.25 seconds

Any data logged is loaded into Microsoft The reception and subsequent transmission
Excel and MATLAB for further analysis. of serial data to and from the top controller is
handled as an asynchronous interrupt-
5.14 Depth Sensor generating event. In addition, other
asynchronous events such as the detection of a
A depth sensor was initially included in the leak, or a thermal overload on an H-bridge are
ROV design specifications, but has not been also handled by the interrupt mechanism.
implemented as yet, as the search for a suitable
sensor, at a “reasonable” price has so far been Figure 5.9 shows a representation of the
unsuccessful. system.

Within the last few days, a “slightly out-of-

spec” PAA-6L pressure transducer from Keller

35
 Initialisation

Interrupt on:
3 second timer: - leak detected
Process RX data
- read temperature sensor - H-bridge thermal overload
- RX/TX with top

0.25 second timer:

- read tilt sensors

Figure 5.9. Bottom controller system block diagram.

36
6. Self-Stabilising Control System output as there is no feedback process. This is
shown in Figure 6.2. Open-loop controllers are
As was discussed in Chapter 1, there are subject to, and cannot react to, external
certain operational problems associated with influences and are unsuitable for use in this
underwater vehicles, primarily to do with project, therefore a closed-loop system has
imaging and manipulators, when they are not been implemented.
sitting level in the water. To counter this, in
this ROV project a control system has been 6.2 Self-Stabilising System Overview
developed to attempt to correct any major
variations in the pitch and roll axes (see The self-stabilising control system,
Appendix H for an explanation of motion configured as a closed-loop controller, is
around these axes). Before examining this designed to react to measured tilts on the pitch
system further however, an overview of and roll axes by applying power to the vertical
control system theory is necessary. thrusters, to induce an inverse rotation around
the relevant axis, to correct the measured tilt.
6.1 Control System Theory Accordingly, any tilt that is measured is
considered the “system error” and it is fed back
In general, any system that can adjust itself, into the correction mechanism.
based on measuring itself, is thought of as a
control system [19]. These control systems are Figure 6.3 shows a block level overview of
commonly known as closed-loop controllers. the control system where the desired tilt is set
to zero and the current tilt level is fed back as
As can be seen in Figure 6.1, the closed- the error.
loop controller adjusts its output based on a
comparison of the desired output with a To examine this control system in further
measurement of the actual output. The detail, only the pitch axis (with only a single
outcome of this comparison (a subtraction) is thruster for control) will be considered. The
known as the “system error”, and this process thruster is controlled by a PWM system (see
is known as “negative feedback”. section 5.9.1) where an input value to the
PWM system gives a certain output level. For
An open-loop controller, on the other hand, example, an input value of 0% equals no
is one whose desired output is set to a certain power applied to the motor, and an input value
value. It simply does not have the ability to of 100% equals maximum power applied to the
adjust itself based on any variation in the motor.

Desired Output Σ error

Output
Controller
Actual Output
+
-

Output
Measurement

Figure 6.1. Closed-loop control system.

Output
Desired Output Actual Output
Controller

Figure 6.2. Open-loop control system.

37
 Desired tilt Σ error
Control System Current tilt
+
-

Tilt measurement

Figure 6.3. Control system overview.

6.3 P Controllers
Step Response
1.5
step
There are many different ways to P

implement a closed loop control system.

Perhaps the simplest method of correcting any
tilt error is to use what is known as a ‘P 1

controller’, where ‘P’ refers to a proportional

Amplitude

multiplier constant [20]. The calculation is

relatively simple: take the measured tilt value,
0.5
multiply it by some constant (Pk) and apply
that to the motor as a PWM percentage.

For example, say the tilt measurement value 0

0 2 4 6 8 10 12 14 16 18 20
obtained from the accelerometer is 0.34202 Time (seconds)
(≈20 degrees), and the Pk constant is 40: Figure 6.4. P controller output where Pk is too low.

(4)
Step Response
2
step
1.8 P

Mathematically, the P controller can be 1.6

stated as: 1.4

1.2
Amplitude

(5) 0.8

0.6
Where:
0.4


0.2
yP(t) is the P controller output
 e(t) is the error input (tilt) 0
0 2 4 6 8 10 12 14 16 18 20


Time (seconds)
Pk is the proportional constant
Figure 6.5. P controller output where Pk is too high.
Unfortunately a P controller it is not ideal:
if the Pk constant is set too low it may never
actually reach the desired level (Figure 6.4), Even with careful adjustment, error,
and if it does, it may simply take too long. overshoot, and oscillation are inherent
Conversely, if the Pk constant is set too high, problems with P controllers, and clearly
the response of the system will overshoot and something that achieves a result closer to the
possibly oscillate and never reach a steady ideal is required.
state at the desired level (Figure 6.5).

38
6.4 PID Controllers
Where:

As Bennett (1993) has said:  yPID(t) is the PID controller output

 e(t) is the error input (tilt)
“... it has been shown repeatedly that in the  Pk is the proportional constant
absence of any knowledge (in terms of a  Ik is the integral constant
dynamical model) of the process to be  Dk is the derivative constant
controlled, the PID controller is the best form
of controller.” [21] The block diagram shown in Figure 6.6
may help visualise the concept.

This statement has led directly to the The addition of the integral and derivative
investigation and implementation of a PID- terms have significant effect on the output of
type controller for this project as a dynamical the controller and, with careful tuning, can
model is not readily available for the pitch tilt often overcome all the problems associated
correction system. with the P controller on its own. These extra
integral and derivative terms come at a cost
however, in complexity and performance, and
6.4.1 An Overview of PID Controllers some systems do not require or justify those
costly additions. Fortunately simpler variations
A PID controller is one that incorporates can work just as well, depending upon the
the P controller previously examined, along system requirements.
with a differential element and an integral
element, hence the P, I and D’s in the title.

Mathematically it can be stated as:

(6)

P
+
Desired tilt = 0 Σ e(t)
I Σ y(t)
PWM Motor Drive
+ +
- +
D

Current tilt

Figure 6.6. PID block diagram.

39
6.4.2 The PI Controller
Step Response
The PI controller is one of the variations of 1.5

the PID controller in that it omits the derivative step

PD
element. It is stated mathematically as:

(7)

Amplitude
The integral term, by accumulating error 0.5
over time helps to reduce the steady state error.
Figure 6.7 shows the result when an integral
constant Ik is added to the P controller. If this
constant is set too high overshoot will result. 0
0 2 4 6 8 10 12 14 16 18 20
Time (seconds)

Step Response
1.5 Figure 6.8. PD controller output.
step
PI

6.4.4 The PID Controller

1

The PID controller is the variant that

Amplitude

includes both the integral element and the

derivative element. Using all three elements
0.5
can result in a response that:

 has a steady state at the desired level

0  quickly reaches a steady state

0 2 4 6 8 10 12 14 16 18 20
Time (seconds) does not over- or under- shoot excessively
 is stable in operation
Figure 6.7. PI controller output.
Figure 6.9 shows the example with all three
PID terms in operation and a comparison with
6.4.3 The PD Controller the previous examples. It can be seen there is
less overshoot than the PI controller gives and
The PD controller is another of the the desired steady-state level is achieved,
variations of the PID controller in that it omits unlike the P controller and PD controller.
the integral element. Mathematically it is
stated as: Step Response
1.5
step
P
(8) PI
PD
PID

The derivative term, by reducing the rate of

Amplitude

change of the output over time, helps to reduce

any overshoot and can therefore improve 0.5
stability. Figure 6.8 shows the result when a
derivative constant Dk is added to the P
controller. Compare this with the output from
the P controller only in Figure 6.4 and you can 0
0 2 4 6 8 10 12 14 16 18 20
see the effect it has. If the derivative constant Time (seconds)

is set too high, increased sensitivity to noise

results which can lead to instability. Figure 6.9. PID controller variant outputs.

40
6.4.5 Tuning a PID-type Controller In addition to the Pk, Ik and Dk constants,
the user is also presented with information on
The process of finding the optimal the rise and settling times, the overshoot
constants Pk, Ik and Dk, for a control system is percentage and peak value, and if the system is
known as ‘tuning’. The tuning process is often considered to be closed-loop stable.
done using mathematical modelling tools. An
example is the MATLAB PID Tuner shown in Of course, all the auto-tuning tools require
Figure 6.10 which will automatically adjust the that you have a model of the dynamic
Pk, Ik and Dk constants to give the optimum behaviour of the system (i.e. a transfer function
response based on a number of adjustable representing your system), and, as will be
parameters such as the response time (via the shown in Chapter 7, without a model the
slider at the bottom) and the type of controller tuning process is simply guess work or tedious
to be used. experimentation.

Figure 6.10. MATLAB’s PID Tuner.

41
6.5 Implementing a PID Controller The system has three cascading ‘gain’
blacks, each with their own transfer function:
Having thus determined that a PID
controller, or variant thereof, may be  PID Controller block
appropriate for this project, implementation  PWM  Motor block
and testing was the next step.  Physical Response block

An incredibly useful element of the mbed These three transfer functions, in the
development platform is the large range of Laplace domain, together give an overall
official ARM-developed, and community- transfer function for the pitch tilt correction
developed library functions available, and the system of:
PID controller library is an excellent example.
Following significant research and evaluation,
and then successful testing, it was decided to
utilise this excellent free-to-use library on the (9)
simple principles of open-source software and
community code reuse.

Actual use of the controller library is trivial: (10)

once the controller object has been instantiated
and initialised, actual operation is simply two
lines of C code: Where the transfer function for the PID
Controller block is:
// send current pitch tilt to PID
controller as current error
pitchCon.setProcessValue(pitchTilt);

// let PID controller do its thing (11)

pitchAdj = pitchCon.compute();

The output of the controller is set to be a The transfer function for the PWM 
value in the range [ -1.0 , 1.0 ] which is Motor block is effectively unity as no
equivalent to the PWM output level in the modification to the magnitude of the signal
range [ -100% , 100% ] that is applied to the occurs, except for removing the sign for
thruster. direction control:
This controller was shown to work well out
of the water: the greater the ROV is tilted, the (12)
faster the thruster motors rotate, and varying
the Pk, Ik and Dk constants showed obvious
variation in the response. Despite the efforts detailed in Chapter 7,
the transfer function for the Physical Response
The obvious next step was to determine the block has not yet been determined:
Pk, Ik and Dk constants by in-water
experimentation. This is detailed in Chapter 7.

6.6 Building a Model of the Pitch

Control System Therefore:

After the initial testing to determine the Pk,

Ik and Dk constants was performed, an effort
(13)
was made to try to build a mathematical model
of the pitch tilt correction system. The block
diagram of the control system is shown in
Figure 6.11.

42
 Only once the transfer function of the pitch The roll tilt correction system operates in a
tilt correction system has been determined, can very similar manner to the pitch tilt correction
the stability and frequency response of the system but with three important differences:
system be examined and determined. Tuning
of the Pk, Ik and Dk constants can then also  includes support for two thrusters
occur so as to ensure an appropriate response operating at half the required power each
time and behaviour.  allows for the opposite rotation of each
thruster required for the necessary
6.7 Additional Aspects of the Self - opposing action
Stabilising Control System as  allows for simultaneous vertical ROV
Implemented positioning by the operator, and tilt
correction by the control system
The pitch tilt correction system as actually
implemented includes a directional element of Currently these simultaneous vertical
pitch control to allow for positive and negative positioning operations have 50% of the power
pitch angles. The magnitude of the response of allocated to each thruster, with the other 50%
the control system is identical regardless of tilt assigned to the control system. It may be
direction, but the rotation direction of the possible to reduce the weighting applied to the
thruster propeller varies depending upon the control system and therefore increase the
sign of the tilt measurement. power available to the operator for vertical
positioning if desired.

PID Controller

P
+
Desired tilt = 0 Σ I Σ PWM  Motor
Physical
Response
+
e(t) [-1,1] + y(t) [-1,1] PWM [0,1] + DIR

- +
D

Current tilt [-1,1]

Figure 6.11. Block diagram of the Pitch Tilt Correction Control System.

43
7. Testing and Measurement identified. For example, during the
development of the top controller, the required
Testing of the many unique elements of this voltage regulator elements were determined
project was an essential and ever-present and put in place and ascertained to work as
requirement, as inadequate testing could easily required before the LCD display (and its
result in catastrophic (i.e. expensive) results. associated backlight with its different power
The general approach was to systematically requirements) was added. In this case, trying to
test each and every change as thoroughly as add an additional power source for the
possible before making another change, and to backlight to the circuit at a later stage could
minimise the times where multiple changes easily have caused issues.
were made simultaneously. Experience has
shown that with multiple simultaneous 7.2 Testing the Tether and the Wiring
changes, trouble-shooting becomes
exponentially more difficult. The communication between the top and
bottom controllers via the tether is performed
Though testing effectively never ceases, using the RS-232 standard. This
once the ROV was shown to be effectively communication system was initially developed
operational the measurement phase and tested using short (less than 10 cm) lengths
commenced. of wire, before any attempt was made to use 30
m of Ethernet cable. This systematic approach
The following sections detail the specific ensured that when the Ethernet cable was
aspects of the testing and measurements finally used, it worked as planned immediately.
undertaken.
The concentration of the motor and light
7.1 Testing the Electronic Circuits wires, and the Ethernet cable into a sealed,
single 18-core cable and plug and socket
Following this principle of making and combination, is a significant possible point-of-
testing individual changes one at a time, the failure, so considerable thought and attention
circuits were built-up element-by-element. The went into it before any work commenced.
approach was to first test each element, both Firstly the many individual wires were
electrically and programmatically, in isolation concentrated inside a plastic box and attached
from the other elements of the system to ensure to two sections of screw-terminals. Each
they performed as required. Only once they connection was individually tested and a full
were proven to work in isolation were they test of the operation of the positioning and
integrated into the evolving system software communications systems was performed to
and circuit built on a breadboard, and tested ensure there were no problems.
with the other elements already put in place.
Construction of the multi-core cable and
This gradual addition, element by element, plug and socket then occurred, with each and
to the working system, with complete testing every solder joint fully tested with a digital
of the software and circuit as each new element multi-meter (DMM). Again, a full test of the
was added, meant that any problems that did operation of the positioning and
occur were relatively easily identified, and communications systems was performed to
only once the entire circuit and its software ensure there were no problems.
were working entirely as required on the
breadboard was it moved onto the more Only once these tests were completed
permanent strip-board. successfully was the concentrator box filled
with a water-proof resin to seal the screw
The other related factor that ensured the terminal connections. These steps can be seen
development proceeded relatively smoothly in Figure 3.3.
was the careful consideration taken to order the
implementation of the elements. Again, this This systematic approach to construction
systematic approach ensured that when any and testing has ensured that, at least so far,
problems did occur they were relatively easily there have been no problems associated with
the tether or the motor wiring.

44
 Due to the failure of the camera module in developed at the multi-core cable entry-point.
February, it has not been possible to fully test It was determined that this was due to poor
the video sub-system in the finished hardware, machining of the end-cap (a consequence of
but during the time it was working, the camera using inappropriate tools in this case) and it
was tested and performed perfectly well. was replaced, this time with a more accurately
machined hole. Further testing has shown this
7.3 Water-Proof Testing of the particular issue has now been resolved.
Enclosure
7.4 Trim Testing
Again, following the principle of making
and testing individual changes one at a time, The effects of positioning ballast elements
the construction and validation of the water- (lead weights, and closed-cell foam) follow the
proof enclosure proceeded step-by-step: Archimedes Principle that objects that displace
more water than they weigh (e.g. foam) create
1. Test empty enclosure with three a positive buoyancy, and objects that displace
unmodified end-caps less water than they weigh (e.g. lead) create a
2. Test enclosure with prototype camera negative buoyancy. The ideal buoyancy for the
window ROV is to be as close to neutrally buoyant as
3. Test enclosure with second prototype possible, and as level as possible. In addition,
camera window for stability, it is optimal to have the positively
4. Test enclosure with multi-core connector buoyant elements physically higher than the
installed negatively buoyant elements to ensure the
5. Test enclosure fitted to the ROV for centre-of-buoyancy is above the centre-of-
trimming mass.
6. Test enclosure fitted to the ROV for
powered testing To that end, two pieces of closed-cell foam
7. Test enclosure fitted to the ROV for PID were attached to the top of the frame and four
measurements lead weights of varying sizes were attached to
8. Test enclosure fitted to the ROV for leak mesh on the bottom of the frame.
location determination
9. Test enclosure to ensure leak has been
prevented

All these tests were performed in local

suburban swimming pools, at varying depths
up to 5 m, in conjunction with the Lodge
Scuba Diving Club.

An early design for a camera window was

one of the first tests performed. Unfortunately,
even before making it into the water, it was
found that the window which had been secured
onto the face of an end-cap using epoxy glue
was not sufficiently well attached. It is
understood now that that particular glue does
not work well with the type of plastic the end-
cap is formed from. An improved window
construction method was designed (detailed in
Chapter 3) and subsequently successfully
tested.

Following the window tests, all tests up to

and including the trimming stage were
successful with no leaks detected, however Figure 7.1. A friendly SCUBA diver is useful when
during the following powered tests a small leak fine-tuning buoyancy.

45
 The weights were distributed as listed in The first test of the operational capabilities
Table 7.1. The differential required between found that the horizontal positioning worked
the front and back, and also between the left exactly as expected, however the vertical
and right, is primarily caused by the weight of positioning would not work: a software bug
the off-centre-mounted multi-core cable. resulted in an incorrect rotation direction of
one of the vertical thrusters. This meant that
Location Weight one thruster was pulling up and the other was
Front left 520 g simultaneously pulling down. This was
Front right 450 g corrected and testing the following week
Rear left 430 g showed both vertical and horizontal
Rear right 420 g positioning worked as required (see Figure
Total 1,820 g 7.2).

Table 7.1. Lead weight distribution.

The positions of each of the four lead

weights were adjusted in each corner to ensure
the ROV was sitting level in the water. Two
large pieces of the closed-cell foam were
initially used to achieve positive buoyancy and
they were then slowly reduced in size until
neutral buoyancy was achieved.

The two remaining pieces of foam each

measure approximately 310 mm × 25 mm × 25
mm. With a volume of approximately 0.2
litres each, they therefore each give
approximately 200 g of buoyancy (based on Figure 7.2. Powered testing in the pool.
the assumption that 1 litre of water weighs
1000 grams). A short video of this is available at
www.youtube.com/watch?v=x2vWEfYG3sE
The total ballast offered by these six
elements can be calculated as: At this point the ROV was deemed to be
effectively operational and the focus of the
(14) testing and measurement then moved to the
control system.

For operation in sea-water, which has a

greater density, some additional trim weights
will be necessary.

A short video taken during the trimming

process is available to watch at:
www.youtube.com/watch?v=-OokiggFwLU

7.5 Powered Testing

Following the successful trim testing, the

next phase of testing the ROV was to ensure it
would actually move through the water
satisfactorily.

46
7.6 Measurements of Dynamics once again this proved in practice to be too
Characteristics for Control System difficult to achieve in the available time frame
Development and so far has been ultimately ineffective.

As detailed in Chapter 6, successful The tests undertaken involved applying a

operation of the PID-based tilt correction varying level of power, from 0% to 100%, to
control system of the ROV requires the the thruster, in both rotational directions, and
determination of the appropriate Pk, Ik, and Dk recording the resulting tilt levels. Any tilt
constants, and a number of attempts were made recorded should represent a response by the
to measure the dynamics characteristics of the system to the application of thrust from the
system in various configurations. thruster by a rotation around the pitch axis.

7.6.1 Varying the PID Constants Figure 7.4 shows the results of the
measured data, and they confirm the physical
The initial attempts at determining the observations made at the time that, rather than
optimum Pk, Ik, and Dk constants involved sitting “mid-water” and rotating as desired, the
operating the ROV in the water, with a ROV was repeatedly driven straight down to
deliberate tilt applied, and cycling through and up from the bottom of the pool by the
varying values of the constants and measuring single operating thruster. Rather
the dynamics characteristics, i.e. the effective disappointingly again, no effective change in
response of the control system, by looking at tilt was observed or recorded for any PWM
the resulting tilt level. It was thought the data level.
recorded may give at least an indication of
suitable values for the PID constants, but this It can be observed at approximately 300
proved in practice to be too difficult to achieve and 700 seconds into the test, when the motor
and was ultimately an ineffective method. is at 100% full power, that there is a change in
the tilt level which could indicate a desirable
Figure 7.3, for example, shows a plot of the response, however it was observed that the
data obtained when the Pk constant was slowly ROV was sitting on the pool bottom at the time
increased from 1 to 50. Before every increase, and it is therefore not considered a reliable
Pk is reset to 1 and the system, at least in observation of the system response by pitch
theory, is allowed to settle. rotation.

What actually happened was that the ROV It can also be observed that at
was simply driven down to the bottom of the approximately 780 seconds into the test a
pool by the single operating thruster, and change has occurred: the rear vertical thruster
stayed there, and rather disappointingly, no was manually rotated around the pitch axis so
effective tilt correction was observed or that instead of being oriented vertically, it was
recorded for any value of Pk. Another set at a 45 tilt. This rotation of the thruster
approach was clearly needed. was done as it was observed from the poolside
that there was no rotation of the ROV about
7.6.2 Varying the PWM Level the pitch axis occurring, and it was thought at
the time that changing the angle may make a
Having been unsuccessful in the numerous difference. In fact it imparted a not
attempts to manually and exhaustively insignificant horizontal force and the ROV
determine the Pk, Ik, and Dk constants, another moved forwards and backwards in the water in
approach was tried, where an effort was made addition to vertically up and down. No
to determine the response of the system to the additional rotation about the pitch axis was
operation of the single vertical rear thruster. observed at the pool side, and this particular
Again, it was thought that any data recorded experiment was deemed a failure.
may give at least an indication of the system
response, which may then lead to building a Finally, a cursory glance at the data post-
model of the system (and from there to 780 seconds seems to show a positive and then
determining the Pk, Ik, and Dk constants), but negative tilt correction occurring, but that was

47
in fact due to the ROV sliding down a steep were never considered in this light. This has
slope in the pool floor. the effect of moving the centroid closer to the
rear vertical thruster, and therefore much lower
A video of the pool session can be seen at: (effectively zero) angular momentum is
www.youtube.com/watch?v=ZuQB57rVeSg imparted by the thruster.

After an examination of this data, and a A number of possible solutions to this

careful re-assessment of the physical design, a problem present themselves:
likely cause of the lack of rotation about the
pitch axis has been discovered. It was always  redesign the frame so that the thrusters are
assumed that due to the near-symmetrical further away from the centre
frame design the centroid, the mid-point  add additional weights (and
between the centre-of-mass and centre-of- correspondingly offsetting foam) to move
buoyancy and the point about which rotation of the centre-of-mass closer to the centre
the ROV would occur, was essentially in the
middle of the frame. It now appears that Unfortunately, due to time constraints neither
assumption was incorrect as the single rear have been investigated further and the problem
vertical thruster plus the multi-core cable and is now listed as work for further consideration.
connectors do actually significantly change the
relative position of the centre-of-mass, but

Pitch Tilt
100
angle (degrees)
80
Tilt (degrees)

60

40

20

-20
0 100 200 300 400 500 600 700 800 900
Time (s)

PID Level
50
P constant
40
P constant

30

20

10

0
0 100 200 300 400 500 600 700 800 900
Time (s)

Figure 7.3. Results from varying the Pk constant.

48
 Pitch Tilt
40
angle (degrees)
20
Tilt (degrees)

-20

-40
0 200 400 600 800 1000 1200
Time (s)
PWM Level
100
PWM (%)
50
PWM (%)

-50

-100
0 200 400 600 800 1000 1200
Time (s)

Figure 7.4. Results from varying the PWM level.

49
8. Conclusions throughout the entire development
process. In-water measurements to
This project started with the overall goal of identify the vehicles’ dynamic
combining personal interests and newly characteristics are still currently
developed skills, to produce a potentially underway and have not been
useful and interesting device, whilst presenting completed.
as many realistic challenges as possible.
 Primary Goal 5: Design and
The project has now ended with that goal implement an automatic control
completely satisfied: an extremely interesting, system for pitch and roll of the
fully working underwater vehicle has been vehicle
designed and constructed, from scratch,
utilising and learning many new skills, and This has been partially achieved. A
overcoming many, many challenges along the working PID controller system has
way. been implemented for both the pitch
and roll axes for tilt correction,
8.1 Results however, tuning of the control system
parameters is still underway.
It would be fair to say that the defined goals
of the project, as set many months ago, may  Secondary Goal 1: Test robustness
not be fully met as yet, however this is really of the control system
more a function of the time available, and to a
lesser degree the finances available, rather than This has been partially completed
any inability to overcome the challenges through the process of measuring the
presented. dynamics characteristics, but until the
control system parameters have been
Looking closer at the specific primary and tuned (Primary Goal 5), this cannot be
secondary goals: completed.

 Primary Goal 1: Build an  Secondary Goal 2: Consider (if

underwater vehicle fitted with needed) any improvements to the
thrusters for horizontal and vertical control system
positioning
This has been completed. Section 8.3
This has been successfully completed. contains this information.

 Primary Goal 2: Build  Secondary Goal 3: Install a video

microcontroller-based electronic camera and lights on the vehicle
circuitry for operating the thrusters
This has been partially completed. A
This has been successfully completed. video camera system was implemented
and was working successfully, but it
 Primary Goal 3: Build remote has since failed, and is currently
operator providing basic interface to awaiting replacement. The addition of
the vehicle lights to the vehicle has been fully
supported but only partially achieved
This has been successfully completed. physically.

 Primary Goal 4: Test the vehicle and 8.2 Analysis

identify its dynamics characteristics
A great deal of thought has gone into every
This has been partially achieved. In- aspect of this project in an attempt to minimise
and out-of-water testing of the vehicle the number of problems that might occur, and
has been an ongoing process given the success of the project so far, it has to
be said that this considered approach has
50
worked to a large degree, but it was always than it appears it should, and everything fails at
known that there would be some major some time. Having reliable and trustworthy
challenges to be faced, particularly in the suppliers was key to minimising the problems
physical construction aspect. these issue cause.

The design and construction of the water- Despite all these difficulties, there were
proof enclosure, was always expected to many positives that came out of this project:
present many difficulties, and so it has proven,
but it is fair to say that the difficulty level was  Many satisfying challenges were faced and
grossly underestimated. A limited budget, and overcome that presented excellent learning
the inability to accurately machine certain opportunities
components, using inappropriate tools, caused  The subject matter was very varied and
many unnecessary headaches, and wasted a very interesting, and this made it actually
considerable amount of time. It can be simply enjoyable, and gave the opportunity to
summarised as: on a limited budget, water- converse with many interested and
proofing is difficult. interesting people from many fields
 The valuable confirmation, from the
Convenient access to a suitable in-water successful outcome of the project, of the
testing environment also proved to be greatly design and testing methodologies
overestimated. Though excellent support was employed, that reaffirms the problem
received from the SCUBA diving club, the solving skills refined over the last 3 years
practical logistics of taking the ROV to the  Many valuable skills were developed or
pool via public transport (in some cases a one refined including:
hour trip requiring 2 busses and a train), just to o embedded C programming
run a single 10 minute test, was inefficient to o circuit design and board layout
say the least. In addition, local swimming o assembly and fabrication
pools are not actually ideal test and  Many new and unfamiliar components and
development environments as they are techniques were used such as:
inconveniently placed, not readily accessible o LIPO batteries
outside SCUBA club sessions, have no pool- o ARM-based micro-controllers on the
side power supplies to run laptops, do not mbed development boards
allow cameras (except under very special o H-bridges, voltage regulators and
circumstances), and offer limited testing space. accelerometers
In addition there are considerable health and o LCD displays
safety issues to deal with as well. A number of o RS232 communications
alternatives were considered, and some even o PID controllers and PWM systems
tried, including a number of home bath tubs,
neighbour’s fish ponds, and a duck pond at a 8.3 Future Work
local common. All were unsuitable for one
reason or another (size and water quality being Throughout the entire project, many
the main issues faced). possible improvements and additions were
envisioned, and suggested by others. Many
When looking at the attempts made to try to were taken on board, however many more
measure the system’s dynamics characteristics, were considered to be simply beyond the scope
it is now obvious that measuring and of this project. Following the completion of
characterising a real world (ie non-linear) this phase of the project, it is hoped that many
device, operating in the real world (a non- of the following ideas will be examined for
linear environment) is actually a difficult and implementation:
complex task and the difficulty level of this
task was also greatly underestimated.
 Depth sensor
 Environmental sensors eg water salinity
Other real-world issues that were faced
and water temperature sensors
include the fact that everything costs more than
is expected, everything takes longer to arrive  Digital compass
than it should, everything takes longer to build  Pan-and-tilt for camera

51
 On-screen data display  Conduct more research and testing to
 Manipulator determine the optimum angle for operation
 On-board battery monitoring of the vertical thrusters
 Longer tether
 Additional cameras and lights Given an unlimited budget, and unlimited
 Fibre optic data link time and space, the following would’ve greatly
 Wireless data link assisted in producing a better outcome:
 PC control
 PCB construction and design-for-  Design and construct a purpose-built
pressure enclosure. This is a relatively
manufacture
expensive exercise (≈£200) but will allow
 Open-sourcing the design, plans, and
greater depths, greater reliability, and
software
greater confidence
 Analog control of horizontal thrusters for
 Construct a home-based testing tank to
finer control
allow for much more convenient in-water
 Obstacle detection
testing. The average home bath tub is
 Autonomous operation simply not large enough. Research into this
 Investigations into alternative control is ongoing.
systems  Invest in better tools, or find conveniently
local ones: personal access to a laser cutter
8.4 Alternative Approaches or CNC mill would be incredibly useful
Throughout the project there have been 8.5 Summary
many decisions made that are, with hindsight,
to be regretted. Most of those have been In summary, this underwater vehicle
relatively minor and the consequences not project, though somewhat daunting at the start,
severe: routing a motor wire through a certain was extremely enjoyable, and yet incredibly
channel for example. Some modifications and challenging at the same time. It was interesting
improvements that would be seriously and varied, included many opportunities to
considered, given the opportunity, however are research and apply new and exciting
noteworthy: techniques and technologies, and allowed for
the development and refinement of new and
 Re-route the 18-core cable to minimise existing skills. It gave the opportunity for
weight distribution offset interesting discussions with interesting people,
 Use multiple 6-conductor connectors and finally, it gave a real insight into actually
instead of a single 18-conductor version developing a product.
 Add a USB-to-wireless data link to the
development PC to allow programming
and debugging without having to remove
the bottom controller from the enclosure

52
9. References

1. Saab Seaeye Ltd, (2009). Seaeye ROV Comparison Chart. [online]

Available from: < http://www.seaeye.com/comparerovs.html>
[Accessed: 18 February 2012]

2. Woods Hole Oceanographic Institution, (2007). Human Occupied Vehicle Alvin. [online
image] Available from: < http://www.whoi.edu/cms/images/v44n1-alvin-
intro1en_12472_36562_82629.jpg > [Accessed 9 February 2012] Used with permission

3. Woods Hole Oceanographic Institution, (2007). Seabed. [online image]

Available from: < http://www.whoi.edu/cms/images/hanu2-en_28930_42353.jpg >
[Accessed 9 February 2012] Used with permission

4. VideoRay LLC, (2011). P4 Product Packaging. [online image]

Available from: < http://www.videoray.com/images/picture/P4PACKAGING_web.jpg >
[Accessed 9 February 2012] Used with permission

5. Saab Seaeye Ltd, (2009). Saab Seaeye Lynx [online image]

Available from: < http://www.seaeye.com/pop.html?image=images/compare-rovs/lynx.jpg >
[Accessed 20 February 2012] Used with permission

6. Saab Seaeye Ltd, (2009). Saab Seaeye Jaguar [online image]

Available from: <http://www.seaeye.com/pop.html?image=images/compare-rovs/jaguar.jpg>
[Accessed: 20 February 2012] Used with permission

7. SMD Ltd, (2011). SMD UT-1 trencher. [online image]

Available from: < http://www.smd.co.uk/resources/page/123_118_128_47_image1_l.jpg >
[Accessed: 18 February 2012] Used with permission

8. Sayers, C. , (1999). Remote Control Robots. New York: Springer.

9. Pelekanakis, K. and Baggeroer, A., (2011). Exploiting Space-Time-Frequency Diversity With

MIMO-OFDM for Underwater Acoustic Communications. IEEE Journal of Oceanic
Engineering. October 2011 36 (4), 502-513.

10. National Defence Research Committee, (1969). Physics of Sound in the Sea. Washington: US
Dept of the Navy.

11. NXP B.V., (2009). mbed NXP LPC 1768 prototyping board. [online]
Available from: < http://www.nxp.com/documents/leaflet/LPC1768.pdf >
[Accessed: 18 February 2012]

12. Powertip Tech. Corp., (2006). PC1602ARU-HWB-G-Q. [online]

Available from: < http://www.farnell.com/datasheets/40247.pdf >
[Accessed: 18 February 2012]

13. National Semiconductor, (2000). LM135/LM235/LM335, LM135A/LM235A/LM335A

Precision Temperature Sensors. [online]
Available from: < http://www.farnell.com/datasheets/36878.pdf >
[Accessed: 18 February 2012]

53
14. STMicroelectronics, (2009).LIS331DLH. [online]
Available from: < http://www.st.com/internet/com/TECHNICAL_RESOURCES/
TECHNICAL_LITERATURE/DATASHEET/CD00213470.pdf >
[Accessed: 18 February 2012]

15. Fairchild Semiconductor, (2004). RFP30N06LE, RF1S30N06LESM Data Sheet. [online]

Available from: < http://www.farnell.com/datasheets/65413.pdf >
[Accessed: 18 February 2012]

16. National Semiconductor, (2011). LMD18200. [online]

Available from: < http://www.farnell.com/datasheets/78246.pdf >
[Accessed: 18 February 2012]

17. Sparkfun Electronics, (2011). CM-26N/P C-MOS Color Camera Module. [online]
Available from: < http://www.sparkfun.com/datasheets/Sensors/Imaging/CM-26N.pdf >
[Accessed: 18 February 2012]

18. Keller Ag., (2009). Keller Piezoresistive OEM Pressure Transducers. [online]
Available from: < http://www.keller-druck.com/picts/pdf/engl/3L_10L_e.pdf >
[Accessed: 18 February 2012]

19. Dickinson, M., (2011). Introduction to Control Engineering. UK: Elektor International Media.

20. Lewis, P. and Yang, C., (1997). Basic Control Systems Engineering. Upper Saddle River:
Prentice-Hall Inc.

21. Bennett, S., (1993). A history of control engineering 1930 - 1955. London: Peter Perigrinus
Ltd.

22. STMicroelectronics, (2010). AN3182 Application note, Tilt measurement using a low-g 3-axis
accelerometer. [online]
Available from: < http://www.st.com/internet/com/TECHNICAL_RESOURCES/
TECHNICAL_LITERATURE/APPLICATION_NOTE/CD00268887.pdf>
[Accessed: 18 February 2012]

54
10. Bibliography
 Bohm, H. and Jensen, V., (2010). Build your own underwater robot and other wet projects.
Vancouver: Westcoast Words.

 van Dam, B., (2010). ARM Microcontrollers, Part 1: 35 projects for beginners. Susteren:
Elektor International Media.

 Roberts, G. and Sutton, R., (2006). Advances in Unmanned Marine Vehicles. Stevenage: The
Institution of Electrical Engineers.

 Antonelli, G., (2003). Underwater Robots, Motion and Force Control of Vehicle-Manipulator
Systems. Berlin: Springer-Verlag.

 N-Nagy, F. and Siegler, A., (1987). Engineering Foundations of Robotics. Englewood Cliffs:
Prentice-Hall Inc.

 Horowitz, P. and Hill, W., (2008). The Art of Electronics. Cambridge: Cambridge University
Press.

 Ly, U., (1997). Stability and Control of Flight Vehicle. [online] Seattle: University of
Washington. Available from: <
http://metalab.uniten.edu.my/~farrukh/mywork/FLIGHT~1.PDF > [Accessed 25 February
2012]

55
11. Appendices
Appendix A - DES Project Specification Form

Title: Underwater remotely operated vehicle

Student Name: Scott O’Brien
Year: 2011/12
Supervisor: Dr. Andrzej Tarczynski
Assessor:
Moderator:

Aims and Description:

To design and build an underwater vehicle with pitch and roll control system

Primary Goals:
1. To build an underwater vehicle fitted with thrusters for horizontal and vertical positioning
2. To build microcontroller-based electronic circuitry for operating the thrusters
3. To build remote operator providing basic interface to the vehicle
4. To test the vehicle and identify its dynamics characteristics
5. To design and implement automatic control system for pitch and roll of the vehicle

Secondary Goals:
1. To test robustness of the control system
2. To consider (if needed) any improvements to the control system
3. To install a video camera and lights on the vehicle

Resources Needed:
 The student will fund the project
 Access to the ECS workshop
 Eagle-CAD (freeware)
 Matlab

Health and Safety Assessment and Arrangements:

 Follow the normal health and safety precautions appropriate to the work performed on the
project.

Supervisor signature:
Date: 10 October 2011

Student signature:
Date: 10 October 2011

56
Appendix B - Top Controller Schematics

Figure B.1. Top controller schematic.

57
Figure B.2. Top controller strip-board layout.

58
Appendix C - Bottom Controller Schematics

Figure C.1. Bottom controller schematic.

59
Figure C.2. Top controller strip-board layout.

60
Appendix D - Top Controller Code

// TOP controller for ROV

// v0.70 24 April 2012
// by Scott O'Brien

// LIBRARIES
#include "mbed.h"
#include "TextLCD.h"

// PIN DEFINITIONS
Serial pc(USBTX, USBRX); // diagnostic connction to PC via USB
Serial topSerial(p13,p14);// tx, rx to bottom cont. via MAX3232

DigitalOut mbedLED1(LED1); // onboard led's

DigitalOut mbedLED2(LED2);
DigitalOut mbedLED3(LED3);
DigitalOut mbedLED4(LED4);

DigitalOut leakLED(p22); // red

DigitalOut linkLED(p23); // green
DigitalOut lightsLED(p24); // green
DigitalOut controlSystemLED(p25); // green
DigitalOut switch3LED(p26); // green

TextLCD lcd(p5,p6,p7,p8,p9,p10,TextLCD::LCD20x4); // 20x4 LCD

AnalogIn leftJoystickUpDownAnalog(p17);
AnalogIn leftJoystickLeftRightAnalog(p18);
AnalogIn rightJoystickUpDownAnalog(p19);
AnalogIn rightJoystickLeftRightAnalog(p20);

AnalogIn tempTop(p16); // temperature sensor

InterruptIn lightsSwitch(p30);
InterruptIn controlSystemSwitch(p29);
InterruptIn switch3(p28);

PwmOut buzzer(p21); // leak alarm buzzer

// TICKERS AND TIMERS

Ticker majorEvent; // major event ticker
Ticker tempSensor; // read temp sensor ticker

// VARIABLES AND CONSTANTS

char raise = 0;
char lower = 0;
char moveLeft = 0;
char moveRight = 0;
char forward = 0;
char reverse = 0;
char turnLeft = 0;
char turnRight = 0;
float topTemp = 0;
char lightsOn = 0;
char controlSystemOn = 0;
char switch3On = 0;
char controlData[3] = {0,0,0}; // data to tx to bottom
char rxData[5] = {0,0,0,0,0}; // data rx from bottom
char rxPCData = 0;
char dataLoggingOn = 0;

61
 float kP = 1.0; // PID "constants"
uint8_t *kP8 = (uint8_t*)&kP;
float kI = 0.0;
uint8_t *kI8 = (uint8_t*)&kI;
float kD = 0.0;
uint8_t *kD8 = (uint8_t*)&kD;

// FUNCTIONS

// send and recieve data from PC via USB

void SendAndReceiveDataFromPC() {
if(pc.readable()) {
rxPCData = pc.getc();
pc.printf("%c",rxPCData);

if (rxPCData == '?') {
pc.printf("\r\n\n\nScottROV\r\nTop Controller v0.70
Bottom Controller v0.70");
pc.printf("\r\nkP = %.4f, kI = %.4f, kD =
%.4f",kP,kI,kD);
pc.printf("\r\nrx[0] = %i, temp = %i, pitch = %i, roll
= %i", rxData[0], rxData[1], rxData[2] - 90,
rxData[3] - 90);
pc.printf("\r\ncontrolData[0] = %i, controlData[1] =
%i",controlData[0],controlData[1]);
if (dataLoggingOn) {
pc.printf("\r\nData logging is ON");
}
else {
pc.printf("\r\nData logging is OFF");
}
if (controlSystemOn) {
pc.printf("\r\nControl system is ON");
}
else {
pc.printf("\r\nControl system is OFF");
}
pc.printf("\r\n\n? = this list\r\nl = toggle data
logger\r\no = toggle control system\r\nt = transfer
data (not enabled)\r\np = change P term\r\ni =
change I term\r\nd = change D term\r\n\n");
}

else if (rxPCData == 'l') {

dataLoggingOn = !dataLoggingOn;
if (dataLoggingOn) {
pc.printf("\r\n\ndata logger turned on\r\n\n");
}
else {
pc.printf("\r\n\ndata logger turned off\r\n\n");
}
}

else if (rxPCData == 'o') {

controlSystemOn = !controlSystemOn;
if (controlSystemOn) {
pc.printf("\r\n\ncontrol system turned on\r\n\n");
}
else {
pc.printf("\r\n\ncontrol system turned off\r\n\n");

62
 }
}

else if (rxPCData == 't') {

pc.printf("\r\nThis feature is not yet enabled, but
data logger has been turned off\r\n\n");
dataLoggingOn = 0;
}

else if (rxPCData == 'p') {

pc.printf("\r\nEnter kP value: ");
pc.scanf ("%f",&kP);
pc.printf("You entered: %.4f\r\n",kP);
}

else if (rxPCData == 'i') {

pc.printf("\r\nEnter kI value: ");
pc.scanf ("%f",&kI);
pc.printf("You entered: %.4f\r\n",kI);
}

else if (rxPCData == 'd') {

pc.printf("\r\nEnter kD value: ");
pc.scanf ("%f",&kD);
pc.printf("You entered: %.4f\r\n",kD);
}

else {
pc.printf("\r\n\ncommand not understood - try
?\r\n\n");
}
}
return;
}

// respond to light switch flipped on

void turnLightsOn() {
wait_ms(25);
if (lightsSwitch == 1) {
lightsLED = 1;
lightsOn = 1;
}
return;
}

// respond to light switch flipped off

void turnLightsOff() {
wait_ms(25);
if (lightsSwitch == 0) {
lightsLED = 0;
lightsOn = 0;
}
return;
}

63
// respond to control system switch flipped on
void turnControlSystemOn() {
wait_ms(25);
if (controlSystemSwitch == 1) {
controlSystemLED = 1;
controlSystemOn = 1;
}
return;
}

// respond to control system switch flipped off

void turnControlSystemOff() {
wait_ms(25);
if (controlSystemSwitch == 0) {
controlSystemLED = 0;
controlSystemOn = 0;
}
return;
}

// respond to switch 3 flipped on

void turnSwitch3On() {
wait_ms(25);
if (switch3 == 1) {
switch3LED = 1;
switch3On = 1;
dataLoggingOn = 1;
}
return;
}

// respond to switch 3 flipped off

void turnSwitch3Off() {
wait_ms(25);
if(switch3 == 0) {
switch3LED = 0;
switch3On = 0;
dataLoggingOn = 0;
}
return;
}

// read joysticks
void read_joysticks(){
// each joystick axis is averaged over 3 samples to eliminate
// any ADC glitches.
if ((leftJoystickUpDownAnalog +
leftJoystickUpDownAnalog +
leftJoystickUpDownAnalog) / 3 > 0.75) {
lower = 32; // 32 = space char, represents not on
raise = 94; // 94 = ^ char, represents on
}
else if ((leftJoystickUpDownAnalog +
leftJoystickUpDownAnalog +
leftJoystickUpDownAnalog) / 3 < 0.25) {
raise = 32;
lower = 118; // 118 = v char, represents on
}
else {
raise = 32;
lower = 32;

64
 }

if ((leftJoystickLeftRightAnalog +
leftJoystickLeftRightAnalog +
leftJoystickLeftRightAnalog )/ 3 < 0.25) {
moveLeft = 32;
moveRight = 126;// 126 = right arrow char represents on
}
else if ((leftJoystickLeftRightAnalog +
leftJoystickLeftRightAnalog +
leftJoystickLeftRightAnalog ) / 3 > 0.75) {
moveRight= 32;
moveLeft = 127; // 127 = left arrow char represents on
}
else {
moveLeft = 32;
moveRight = 32;
}

if ((rightJoystickUpDownAnalog +
rightJoystickUpDownAnalog +
rightJoystickUpDownAnalog) / 3 > 0.75) {
reverse = 32; // 32 = space char, represents not on
forward = 94; // 94 = ^ char, represents on
}
else if ((rightJoystickUpDownAnalog +
rightJoystickUpDownAnalog +
rightJoystickUpDownAnalog) / 3 < 0.25) {
forward = 32;
reverse = 118; // 118 = v char, represents on
}
else {
forward = 32;
reverse = 32;
}

if ((rightJoystickLeftRightAnalog +
rightJoystickLeftRightAnalog +
rightJoystickLeftRightAnalog) / 3 < 0.25) {
turnLeft = 32;
turnRight = 126;// 126 = right arrow char represents on
}
else if ((rightJoystickLeftRightAnalog +
rightJoystickLeftRightAnalog +
rightJoystickLeftRightAnalog) / 3 > 0.75) {
turnRight= 32;
turnLeft = 127; // 127 = left arrow char, represents on
}
else {
turnLeft = 32;
turnRight = 32;
}
return;
}

// output data to lcd screen

void display_data() {

lcd.locate(1,1); lcd.printf("L"); // left joystick

lcd.locate(0,1); lcd.putc(moveLeft);
lcd.locate(2,1); lcd.putc(moveRight);

65
lcd.locate(1,0); lcd.putc(raise);
lcd.locate(1,2); lcd.putc(lower);

lcd.locate(4,1); lcd.printf("R"); // right joystick

lcd.locate(3,1); lcd.putc(turnLeft);
lcd.locate(5,1); lcd.putc(turnRight);
lcd.locate(4,0); lcd.putc(forward);
lcd.locate(4,2); lcd.putc(reverse);

lcd.locate(6,1); lcd.printf("P"); // PID settings

lcd.locate(7,1); lcd.printf("%2.1f",kP);
lcd.locate(6,2); lcd.printf("I");
lcd.locate(7,2); lcd.printf("%2.1f",kI);
lcd.locate(6,3); lcd.printf("D");
lcd.locate(7,3); lcd.printf("%2.1f",kD);

lcd.locate(11,2); lcd.printf("P"); // pitch tilt level

lcd.locate(12,2); lcd.printf("%3i",rxData[2] - 90);
lcd.locate(11,3); lcd.printf("R"); // roll tilt level
lcd.locate(12,3); lcd.printf("%3i",rxData[3] - 90);

lcd.locate(16,2); lcd.printf("T"); // top temp

lcd.locate(17,2); lcd.printf("%2.0f",topTemp);
lcd.locate(19,2); lcd.putc(223); // degree symbol

lcd.locate(16,3); lcd.printf("B"); // bottom temp

lcd.locate(17,3); lcd.printf("%2.0i",rxData[1]);
lcd.locate(19,3); lcd.putc(223);

lcd.locate(6,0); if ((rxData[0] & 135) == 135) {

lcd.printf("LEAK");
buzzer.pulsewidth_us(250);
leakLED = 1;
}

else {
lcd.printf(" ");
buzzer.pulsewidth_us(0);
leakLED = 0;
}

lcd.locate(11,0); if ((rxData[0] & 184) == 184) {

lcd.printf(”TEMP”);
}

else {
lcd.printf(" ");
}

lcd.locate(0,3); if(lightsOn) {
lcd.putc('L');
}
else {
lcd.putc(32);
}

lcd.locate(1,3); if(controlSystemOn) {
lcd.putc('C');
}
else {
lcd.putc(32);

66
 }
lcd.locate(2,3); if(dataLoggingOn) {
lcd.putc('D');
}
else {
lcd.putc(32);
}
return;
}

void send_and_receive_data(){
linkLED = !linkLED;

// build tx data byte controlData[0]

// bit 0: front right thruster, on = 1
// 1: front left thruster, on = 1
// 2: rear right thruster, on = 1
// 3: rear left thruster, on = 1
// 4: lights, on = 1
// 5: control system, on = 1
// 6: data logging, on = 1
// 7: reserved, set to 1, signifies byte controlData[0]

controlData[0] = 128; // set bit 7

if (forward == 94) {
controlData[0] = controlData[0] + 3; // set bits 0 & 1
}

if (reverse == 118) {
controlData[0] = controlData[0] + 12;// set bits 2 & 3
}

if (turnRight == 126) {
controlData[0] = controlData[0] + 6; // set bits 1 & 2
}

if (turnLeft == 127) {
controlData[0] = controlData[0] + 9; // set bits 0 & 3
}

if (moveRight == 126) {
controlData[0] = controlData[0] + 10;// set bits 1 & 3
}

if (moveLeft == 127) {
controlData[0] = controlData[0] + 5; // set bits 0 & 2
}

if (lightsOn == 1) {
controlData[0] = controlData[0] + 16;// set bit 4
}

if (controlSystemOn == 1) {
controlData[0] = controlData[0] + 32;// set bit 5
}

if (dataLoggingOn ==1) {
controlData[0] = controlData[0] + 64;// set bit 6
}

67
 // build tx data byte controlData[1]
// bit 0: go up = 1
// 1: go down = 1
// 2: unused, set to 0
// 3: unused, set to 0
// 4: unused, set to 0
// 5: unused, set to 0
// 6: unused, set to 0
// 7: reserved, set to 0, signifies byte controlData[1]

controlData[1] = 0;

if (raise == 94) {
controlData[1] = 1; // this sets bit 0 only
}

if (lower == 118) {
controlData[1] = 2; // this sets bit 1 only
}

// send data via serial connection

if(topSerial.writeable()) {
mbedLED1=!mbedLED1;
topSerial.putc(controlData[0]);
topSerial.putc(controlData[1]);

// send PID constant float values as 4 x 8 bit chars

topSerial.putc(kP8[0]);
topSerial.putc(kP8[1]);
topSerial.putc(kP8[2]);
topSerial.putc(kP8[3]);

topSerial.putc(kI8[0]);
topSerial.putc(kI8[1]);
topSerial.putc(kI8[2]);
topSerial.putc(kI8[3]);

topSerial.putc(kD8[0]);
topSerial.putc(kD8[1]);
topSerial.putc(kD8[2]);
topSerial.putc(kD8[3]);
}

// receive data via serial connection

if(topSerial.readable()) {
rxData[0] = topSerial.getc();
rxData[1] = topSerial.getc();
rxData[2] = topSerial.getc();
rxData[3] = topSerial.getc();

}
return;
}

// read temp sensor called by ticker

void read_temp_sensor(){
// average of 3 readings: single reading * 3.3V * 100
topTemp = ((tempTop + tempTop + tempTop) * 110) - 273;
return;
}

68
// major events called by ticker
void majorEventFunctions () {
read_joysticks();
display_data();
send_and_receive_data();
return;
}

// MAIN
int main() {
// startup display
leakLED = 1;
lcd.cls();
lcd.printf(" SCOTTROV \n\n");
lcd.printf("Top: v0.70 24.4.12\n");
lcd.printf("Bot: v0.70");
wait(3);
lcd.cls();
leakLED = 0;

// set up serial comms to bottom

topSerial.baud(38400);

// set up comms with pc to trigger by interrupt on data arrival

pc.attach(&SendAndReceiveDataFromPC, Serial::RxIrq);

// set up buzzer PWM

buzzer.period_us(500); // 500uS for 2kHz tone

// set up ticker events

tempSensor.attach(&read_temp_sensor, 3.0); // read every 3s
majorEvent.attach(&majorEventFunctions, 0.05); // 20 times / s

// set up interrupts for control panel switches

lightsSwitch.rise(&turnLightsOn);
lightsSwitch.fall(&turnLightsOff);

controlSystemSwitch.rise(&turnControlSystemOn);
controlSystemSwitch.fall(&turnControlSystemOff);

switch3.rise(&turnSwitch3On);
switch3.fall(&turnSwitch3Off);

// determine initial switch state

if (lightsSwitch == 1) {
lightsLED = 1;
lightsOn = 1;
}
else {
lightsLED = 0;
lightsOn = 0;
}

if (controlSystemSwitch == 1) {
controlSystemLED = 1;
controlSystemOn = 1;
}
else {
controlSystemLED = 0;
controlSystemOn = 0;
}

69
 if (switch3 == 1) {
switch3LED = 1;
switch3On = 1;
}
else {
switch3LED = 0;
switch3On = 0;
}

while(1) {

}// end while

}// end of MAIN

70
Appendix E - Bottom Controller Code

// BOTTOM controller for ROV

// v0.70 26 April 2012
// by Scott O'Brien

// LIBRARIES
#include "mbed.h"
#include "LIS331.h" // accelerometer library
#include "SDFileSystem.h" // SD card library for data logging
#include "PID.h" // PID controller library

// COMPILER DEFINITIONS
#define PI 3.14159265

// PIN DEFINITIONS
Serial pc(USBTX, USBRX); // diagnostic conn. to PC via USB
Serial bottomSerial(p13,p14);// tx, rx to top cont. via MAX3232

DigitalOut mbedLED1(LED1); // onboard led's

DigitalOut mbedLED2(LED2);
DigitalOut mbedLED3(LED3);
DigitalOut mbedLED4(LED4);
DigitalOut lights(p12); // external lights

SDFileSystem sd(p5, p6, p7, p8, "sd"); // data logging

LIS331 accel(p9, p10); // I2C conn. to accelerometer

DigitalOut motorHFL(p27); // front left horizontal thruster

DigitalOut motorHFR(p26); // front right horizontal thruster
DigitalOut motorHRL(p25); // rear left horizontal thruster
DigitalOut motorHRR(p24); // rear right horizontal thruster
PwmOut motorVL(p23); // left vertical thruster
DigitalOut motorVLdir(p20); // 0 = down, 1 = up
PwmOut motorVR(p22); // right vertical thruster
DigitalOut motorVRdir(p19); // 0 = down, 1 = up
PwmOut motorVB(p21); // back vertical thruster
DigitalOut motorVBdir(p18); // 0 = down, 1 = up

InterruptIn thermalOverload(p17); // thermal overload flag

InterruptIn leakDetector(p11); // leak detectors
AnalogIn tempBottom(p15); // temperature sensor

PID pitchCon(1.0, 0.0, 0.0, 0.1); // Kp, Ti, Td, interval

PID rollCon(1.0, 0.0, 0.0, 0.1); // Kp, Ti, Td, interval

// TICKERS AND TIMERS

Ticker readSensors; // enable sensor timer
Ticker readTiltSensors; // enable tilt sensor timer
Timer loggingTimer; // timer for data logging

// VARIABLES AND CONSTANTS

char controlData[3] = {0,0,0};// control data rx from top
char txData[5] = {0,0,0,0}; // data tx to top
char controlSystemOn = 0;
char thermalOverloadFlag = 0;
float bottomTemp = 0;
float pitchTilt = 0;
float rollTilt = 0;
char dataLoggingOn = 0;
float kP = 1.0; // PID "constants"

71
 uint8_t kP8[5] = {0,0,0,0,0};
float kI = 0.0;
uint8_t kI8[5] = {0,0,0,0,0};
float kD = 0.0;
uint8_t kD8[5] = {0,0,0,0,0};
float kPID = 0; // change in PID settings?

// level of VB thruster to control pitch, from PID controller

float pitchAdj = 0;
// level of VL/R thrusters to control roll, from PID controller
float rollAdj = 0;

// FUNCTIONS

// interrupt function for serial comms

void sendAndReceiveData() {
mbedLED2 = !mbedLED2;
if(bottomSerial.readable()) {
controlData[0] = bottomSerial.getc();
controlData[1] = bottomSerial.getc();

kP8[0] = bottomSerial.getc(); // PID constants (float) as

kP8[1] = bottomSerial.getc(); // 4 x 8 bit chars
kP8[2] = bottomSerial.getc();
kP8[3] = bottomSerial.getc();

kI8[0] = bottomSerial.getc();
kI8[1] = bottomSerial.getc();
kI8[2] = bottomSerial.getc();
kI8[3] = bottomSerial.getc();

kD8[0] = bottomSerial.getc();
kD8[1] = bottomSerial.getc();
kD8[2] = bottomSerial.getc();
kD8[3] = bottomSerial.getc();

kP = *((float *)kP8); // 4 x 8 chars back to single floats

kI = *((float *)kI8);
kD = *((float *)kD8);

if ((kP + kD + kI) != kPID) { // check for any changes

pitchCon.setTunings(kP,kI,kD);
rollCon.setTunings(kP,kI,kD);
kPID = kP + kD + kI;
}
}

if(bottomSerial.writeable()) {
bottomSerial.putc(txData[0]);
bottomSerial.putc(txData[1]);
bottomSerial.putc(txData[2]);
bottomSerial.putc(txData[3]);
}
return;
}

72
// interrupt function to respond to leak detector
void leakDetected() {
txData[0] = (txData[0] | 135); // set bits 0-2, 7
return;
}

// interrupt function to respond to thermal overload on h-bridges

void thermalOverloaded() {
txData[0] = (txData[0] | 184); // set bits 3-5, 7
thermalOverloadFlag = 1;
return;
}

// read temp & voltage sensors

void read_sensors(){
bottomTemp = ((tempBottom + tempBottom + tempBottom) * 110.0) -
273; // take average of 3 readings
txData[1] = ((char)bottomTemp) & 127;
return;
}

// read tilt sensors

void read_tilt_sensors(){
pitchTilt = (accel.getAccelX() + accel.getAccelX() +
accel.getAccelX() + accel.getAccelX() + accel.getAccelX()) / 5;

rollTilt = (accel.getAccelY() + accel.getAccelY() +

accel.getAccelY() + accel.getAccelY() + accel.getAccelY()) / 5;

if (controlSystemOn == 1) {

// send current pitch tilt to PID controller as current error

pitchCon.setProcessValue(pitchTilt);
// let PID controller do its thing
pitchAdj = pitchCon.compute();

// send current roll tilt to PID controller as current error

rollCon.setProcessValue(rollTilt);
// let PID controller do its thing
rollAdj = rollCon.compute();
}

else {
pitchAdj = 0;
rollAdj = 0;
}
// conv to degs, +90 to ensure +ve number to enable TX as char
txData[2] = (asin(pitchTilt) * 180 / PI) + 90;
txData[3] = (asin(rollTilt) * 180 / PI) + 90;
return;
}

73
// log data
void log_data(){
FILE *fp = fopen("/sd/data.txt", "a");
mbedLED3 = !mbedLED3;
fprintf(fp, "\n\r%f,%i,%f,%f,%f,%f,%f,%f,%f,%f,%i,%f,%i,%f,%i",
loggingTimer.read(), controlSystemOn, kP, kI, kD, pitchTilt,
pitchAdj, rollTilt, rollAdj, motorVL.read(), motorVLdir.read(),
motorVR.read(), motorVRdir.read(), motorVB.read(),
motorVBdir.read());
fclose(fp);
return;
}

// MAIN
int main() {

// initialise timer for data logging

loggingTimer.start();

// initialise all motors

motorHFL = 0;
motorHFR = 0;
motorHRL = 0;
motorHRR = 0;
motorVL = 0.0;
motorVLdir = 0;
motorVR = 0.0;
motorVRdir = 0;
motorVB = 0.0;
motorVBdir = 0;

// init comms to top cont. to trigger by interrupt on data arrival

bottomSerial.baud(38400);
bottomSerial.attach(&sendAndReceiveData, Serial::RxIrq);

// init interrupt for leak detector & thermal overload on h-bridges

// attach address of the leakDetected function to the rising edge

leakDetector.rise(&leakDetected);

// attach address of thermalOverloaded function to the falling edge

thermalOverload.fall(&thermalOverloaded);

// set up ticker event for temp and voltage sensors

readSensors.attach(&read_sensors, 3.0); // read every 3 seconds

// set up accelerometer
accel.setFullScaleRange2g(); // 2g range on accel
accel.setPowerMode(47); // 100 Hz ODR
readTiltSensors.attach(&read_tilt_sensors, 0.250); // every 0.25s

// set up PWM for vertical thrusters

int pwmPeriod = 100; // 100 microseconds = 10 kHz
motorVL.period_us(pwmPeriod);
motorVR.period_us(pwmPeriod);
motorVB.period_us(pwmPeriod);

// set up PID controller for pitch

pitchCon.setInputLimits(-1.0, 1.0); // Input from accelerometer
pitchCon.setOutputLimits(-1.0, 1.0); // PWM output limits
pitchCon.setBias(0.0); // Only if there needs to be a bias.

74
pitchCon.setMode(AUTO_MODE);
pitchCon.setSetPoint(0.0); // Target is to be zero degrees

// set up PID controller for roll

rollCon.setInputLimits(-1.0, 1.0); // Input from accelerometer
rollCon.setOutputLimits(-0.5, 0.5); // PWM output limits
rollCon.setBias(0.0); // Only if there needs to be a bias.
rollCon.setMode(AUTO_MODE);
rollCon.setSetPoint(0.0); // Target is to be zero degrees

while(1) {

// rx data byte controlData[0]

// bit 0: front right thruster, on = 1
// 1: front left thruster, on = 1
// 2: rear right thruster, on = 1
// 3: rear left thruster, on = 1
// 4: lights, on = 1
// 5: control system, on = 1
// 6: data logging, on = 1
// 7: reserved, set to 1, signifies byte controlData[0]

// rx data byte controlData[1]

// bit 0: go up = 1
// 1: go down = 1
// 2: unused, set to 0
// 3: unused, set to 0
// 4: unused, set to 0
// 5: unused, set to 0
// 6: unused, set to 0
// 7: reserved, set to 0, signifies byte controlData[1]

if ((controlData[0] & 131) == 131) { // go forward

motorHFL = 1; motorHFR = 1;
motorHRL = 0; motorHRR = 0;
}

else if ((controlData[0] & 140) == 140) { // go backwards

motorHFL = 0; motorHFR = 0;
motorHRL = 1; motorHRR = 1;
}

else if ((controlData[0] & 134) == 134) { // turn right

motorHFL = 1; motorHFR = 0;
motorHRL = 0; motorHRR = 1;
}

else if ((controlData[0] & 137) == 137) { // turn left

motorHFL = 0; motorHFR = 1;
motorHRL = 1; motorHRR = 0;
}

else if ((controlData[0] & 138) == 138) { // move right

motorHFL = 1; motorHFR = 0;
motorHRL = 1; motorHRR = 0;
}

else if ((controlData[0] & 133) == 133) { // move left

motorHFL = 0; motorHFR = 1;
motorHRL = 0; motorHRR = 1;
}

75
else { // do nothing
motorHFL = 0; motorHFR = 0;
motorHRL = 0; motorHRR = 0;
}

if ((controlData[0] & 144) == 144) { // lights on

lights = 1;
}
else { // lights off
lights = 0;
}

if ((controlData[0] & 160) == 160) { // control system on

controlSystemOn = 1;
}
else {
controlSystemOn = 0; // control system off
pitchAdj = 0;
rollAdj=0;
}

if((controlData[0] & 64) == 64) { // data logging on

dataLoggingOn = 1;
log_data();
}
else {
dataLoggingOn = 0; // data logging off
}

if (((controlData[1] & 1) == 1) &&

(thermalOverloadFlag == 0)) { // go up
// turn on 50%, dir: 0 = down, 1 = up
motorVL = 0.5 + (rollAdj/2); motorVLdir = 1;
// turn on 50%, dir: 1 = down, 0 = up
motorVR = 0.5 - (rollAdj/2); motorVRdir = 0;
}

else if (((controlData[1] & 2) == 2) &&

(thermalOverloadFlag == 0)) { // go down
// turn on 50%, dir: 0 = down, 1 = up
motorVL = 0.5 + (rollAdj/2); motorVLdir = 0;
// turn on 50%, dir: 1 = down, 0 = up
motorVR = 0.5 - (rollAdj/2); motorVRdir = 1;
}

else { // don't drive up or down, turn off all vertical

// thrusters except for control system adjustments
if (rollAdj < 0) {
motorVL = abs(rollAdj)/2; motorVLdir = 0;
motorVR = abs(rollAdj)/2; motorVRdir = 0;
}
else {
motorVL = rollAdj/2; motorVLdir = 1;
motorVR = rollAdj/2; motorVRdir = 1;
}

motorVB = abs(pitchAdj); // control system adjustment

if (pitchAdj < 0) { // determine rotation
motorVBdir = 1;
}

76
 else {
motorVBdir = 0;
}

}// end of while

} // end of main

77
Appendix F - Data Logging Code

Bottom Pitch Data Logger

// BOTTOM controller PITCH DATA LOGGER for ROV

// v0.30
// 18 April 2012
// by Scott O'Brien

// LIBRARIES
#include "mbed.h"
#include "LIS331.h" // accelerometer library
#include "SDFileSystem.h" // SD card library for data logging

// COMPILER DEFINITIONS
#define PI 3.14159265

// PIN DEFINITIONS
DigitalOut mbedLED1(LED1); // onboard led's
DigitalOut mbedLED2(LED2);
DigitalOut mbedLED3(LED3);
DigitalOut mbedLED4(LED4);

SDFileSystem sd(p5, p6, p7, p8, "sd"); // for data logging

LIS331 accel(p9, p10); // I2C connection to accelerometer

DigitalOut motorHFL(p27); // front left horizontal thruster

DigitalOut motorHFR(p26); // front right horizontal thruster
DigitalOut motorHRL(p25); // rear left horizontal thruster
DigitalOut motorHRR(p24); // rear right horizontal thruster
PwmOut motorVL(p23); // left vertical thruster
DigitalOut motorVLdir(p20); // 0 = down, 1 = up
PwmOut motorVR(p22); // right vertical thruster
DigitalOut motorVRdir(p19); // 0 = down, 1 = up
PwmOut motorVB(p21); // back vertical thruster
DigitalOut motorVBdir(p18); // 0 = down, 1 = up

// TICKERS AND TIMERS

Timer loggingTimer; // timer for data logging
Ticker change_VB_PWM_ticker;// change PID settings every 15s

// VARIABLES AND CONSTANTS

float pitchTilt = 0;
float VBLevel = 0;// amount to apply to VB thruster
char VB_incrementer_dir = 0;// increment (0) or decrement (1)
char passes = 0;// number of logging cycles
FILE *fp = fopen("/sd/data.txt", "a");

// FUNCTIONS

// read tilt sensors

void read_tilt_sensors(){

// get samples and take the MODE

int n = 7;
float sample[7] = {0,0,0,0,0,0,0};
for (int i = 0 ; i < n ; i++) { // get samples
sample[i] = accel.getAccelX();
}

78
 for(int i = 0 ; i < n; i++) { // sort the samples
for(int j = 0 ; j < n - 1 ; j++) {
if(sample[j] > sample[j + 1]) {
float temp = sample[j + 1];
sample[j + 1] = sample[j];
sample[j] = temp;
}
}
}

pitchTilt = sample[3];// use value from the middle of the array

return;
}

// log data
void log_data(){

if (fp != NULL) {
FILE *fp = fopen("/sd/data.txt", "a");
}
mbedLED3 = !mbedLED3;
fprintf(fp, "\n\r%f,%f,%f,%i", loggingTimer.read(), pitchTilt,
motorVB.read(), motorVBdir.read());
fclose(fp);
return;

// change VB PWM levels every 5 seconds

void change_VB_PWM(){

if (VBLevel >= 1.0) { // time to head down

VB_incrementer_dir = 1;
}

if (VBLevel <= -1.0) { // time to head up

VB_incrementer_dir = 0;
passes = passes + 1;
}

if (VB_incrementer_dir == 0) {
VBLevel = VBLevel + 0.05; // increment PWM by 5% every step
}
else {
VBLevel = VBLevel - 0.05; // decrement PWM by 5% every step
}

mbedLED2 = !mbedLED2;
return;
}

79
// MAIN
int main() {

wait(30); // time to get in the water

// initialise timer for data logging

loggingTimer.start();

// set up ticker event to change PWM settings every 5 seconds

change_VB_PWM_ticker.attach(&change_VB_PWM, 5.0);

// initialise all motors

motorHFL = 0;
motorHFR = 0;
motorHRL = 0;
motorHRR = 0;
motorVL = 0.0;
motorVLdir = 0;
motorVR = 0.0;
motorVRdir = 0;
motorVB = 0.0;
motorVBdir = 0;

// set up accelerometer
accel.setFullScaleRange2g(); // 2g range on accel
accel.setPowerMode(47); // 100 Hz ODR : 0d47 = 0x2f

// set up PWM for vertical thrusters

int pwmPeriod = 100; // 1 millisecond = 1000 Hz
motorVL.period_us(pwmPeriod); // 1 microsecond = 1 MHz
motorVR.period_us(pwmPeriod); // 100 microseconds = 10 kHz
motorVB.period_us(pwmPeriod);

mbedLED4 = 0; // LED4 turns on when finished data logging

while(1) {
read_tilt_sensors();

if (passes == 5) { // logged enough data yet?

change_VB_PWM_ticker.detach();// disable PWM
mbedLED4 = 1; // turn on "Done” LED4
VBLevel = 0; // turn off VB thruster
}
else {
log_data();
}

motorVB = abs(VBLevel); // apply variable

if (VBLevel < 0) { // determine rotation
motorVBdir = 1;
}
else {
motorVBdir = 0;
}

}// end of while

} // end of main

80
MATLAB

%% PWM pitch data analysis

%
% By Scott O'Brien
% #12747212
%

%% Initialise
clear all; close all; clc;

%% Import data
rawData = importdata('data_pwm_pitch_logger_pool_22_april.txt');

%% Prep data
timeData = rawData(:,1);
pitchTiltData = rawData(:,2);
VBMotorLevelData = rawData(:,3);
VBMotorDirData = rawData(:,4);

% convert accelerometer readings to degrees

pitchTiltAngle = (asin(pitchTiltData) * 180 / pi);

% adjust for direction of rotation

for n = 1:length(VBMotorLevelData);
if VBMotorDirData(n) == 0
VBMotorLevelData(n) = VBMotorLevelData(n) * -1;
end
end

%% Plot tilt and PWM level

figure(1);
hold on;

subplot(2,1,1), plot(timeData,pitchTiltAngle,'r');
legend('angle (degrees)'); title('Pitch Tilt');
xlabel('Time (s)'); ylabel('Tilt (degrees)');
grid on;

subplot(2,1,2),plot(timeData,VBMotorLevelData*100,'b');
legend('PWM (%)'); title('PWM Level');
xlabel('Time (s)'); ylabel('PWM (%)');
grid on;

%% PID pitch data analysis

%
% By Scott O'Brien
% #12747212
%

%% Initialise
clear all; close all; clc;

%% Import data
rawData = importdata('data_pid_pool_12_April_2012.txt');

%% Prep data
timeData = rawData(:,1);

81
p_constant = rawData(:,2);
i_constant = rawData(:,3);
d_constant = rawData(:,4);
pitchTiltData = rawData(:,5);

% convert accelerometer readings to degrees

pitchTiltAngle = (asin(pitchTiltData) * 180 / pi);

%% Plot tilt and PID constants

figure(1);
hold on;

subplot(2,1,1), plot(timeData,pitchTiltAngle,'r');
legend('angle (degrees)'); title('Pitch Tilt');
xlabel('Time (s)'); ylabel('Tilt (degrees)');
grid on;

subplot(2,1,2),plot(timeData,p_constant,'b');
legend('P constant'); title('PID Level');
xlabel('Time (s)'); ylabel('P constant');
grid on;

82
Appendix G - IMU Schematic and PCB Design

Figure G.1. Circuit schematic for Tim Marvin’s IMU board.

83
Figure G.2. PCB design for Tim Marvin’s IMU board.

84
Appendix H - Definitions of Motion

There are six different motions a vessel in

or on water can experience:

 Yaw
 Pitch
 Roll
 Sway
 Surge
 Heave

These are shown in Figure H.1. Sway,

surge and heave are positional movements
along the three axes, whereas yaw, pitch and
roll are rotational movements around those
three axes.

Sway
Top View Yaw

Side View
Surge

Heave

Front View

Figure H.1. Water-based vehicular motions.

85
Appendix I - Accelerometer Noise Further investigation seemed warranted. The
power supply and the USB communications
Analysis were considered and eliminated as possible
sources of this noise, and a low pass filter,
During initial testing of the LIS331DLH
using an averaging over 10 samples, was used
accelerometer, some unexpected glitches were
to try to eliminate it, but this did not eliminate
observed in the raw output data.
the problem.
15 seconds of data readings were logged
A frequency analysis of the data in Matlab
whilst the accelerometer was sitting motionless
was performed to look for clues (Figure I.2). It
on a relatively level table. As can be seen in
was observed that the unwanted noise bears a
Figure I.1, most of the time the reading is -
strong visual resemblance to the MATLAB
0.000061 which is near enough to level, but
uniform noise function. Figure I.3 shows the
every now and then a value of -0.015747
plot of data generated by the rand() function
occurs. It was determined that it was not
and the similarity is obvious.
anything mechanical on or around the table
causing this, as the number never varies from
these two exact figures – external mechanical
disturbances show up as varying values.

x-axis reading
-0.0180
-0.0160
-0.0140
-0.0120
-0.0100
-0.0080
-0.0060 Figure I.2. Signal and noise generated at an output
data rate (ODR) of 1000 Hz.
-0.0040
-0.0020
0.0000
2.5
0.0
1.2

3.7
5.0
6.2
7.5
8.7
10.0
11.3
12.6
13.9

Figure I.1. Logged data generated at an output data

rate (ODR) of 1000 Hz.

These glitches were some sort of noise,

representing 0.9 degrees of tilt [22]:

Figure I.3. Uniform noise generated by the rand()

function.

0.9

86
 After further research, it was found that
noise is common and inherent in these forms of
incredibly sensitive MEM’s based devices.
The manufacturers recommended solution is to
lower the default output data rate (ODR) from
1000 Hz to 100 Hz.

Further testing, including logging more data

and performing frequency analyses shows that
reducing the ODR does in fact lower the noise
floor and reduces the number of spurious
samples received. This is shown in Figures I.4
and I.5. By comparing the vertical axes of
Figures I.2 and I.5 it can be seen there is a
reduction in the average noise levels from
approximately 0.1 down to approximately Figure I.5. Signal and noise generated at an output
0.03. data rate (ODR) of 100 Hz.

As the spurious samples are now received

very infrequently, simply using the mode of 5
x-axis reading or 7 samples should be enough, in practice, to
-0.0180 remove any problem they cause.

-0.0160 The raw data, Excel and MATLAB files

-0.0140
can be found on the accompanying CD.

-0.0120

-0.0100

-0.0080

-0.0060

-0.0040

-0.0020

0.0000
0.02
1.37
2.73
4.08
5.44
6.79
8.14
9.50
10.89
12.32
13.74

Figure I.4. Logged data generated at an output data

rate (ODR) of 100 Hz.

87
 Appendix J - Bill of Materials

Bill of Materials: Top Controller All prices include VAT

Item Quantity Price each Total Supplier
mbed 1 £ 48.88 £ 48.88 Donated by ARM
joystick 2 £ 2.45 £ 4.90 Proto-Pic
joystick breakout board 2 £ 1.50 £ 3.00 Proto-Pic
LCD screen 1 £ 15.60 £ 15.60 Farnell
large stand-offs 8 £ 0.36 £ 2.88 Proto-Pic
small standoffs 8 £ 0.15 £ 1.20 Proto-Pic
bolts 32 £ 0.03 £ 0.96 Proto-Pic
washers 32 £ 0.02 £ 0.64 Proto-Pic
3 junction screw terminal 2 £ 0.25 £ 0.50 Farnell
MAX3232 IC 1 £ 1.84 £ 1.84 Donated by Exar
2x5 way IDC plug 1 £ 1.09 £ 1.09 Maplin
2x5 way IDC socket 1 £ 1.14 £ 1.14 Maplin
2x8 way IDC plug 1 £ 1.19 £ 1.19 Maplin
2x8 way IDC socket 1 £ 1.29 £ 1.29 Maplin
20 pin header strip 2 £ 0.59 £ 1.18 Farnell
16 pin DIL socket 1 £ 0.15 £ 0.15 Farnell
switch 4 £ 1.20 £ 4.80 Farnell
green LED 5 £ 0.20 £ 1.00 Farnell
red LED 1 £ 0.19 £ 0.19 Farnell
enclosure 1 £ 3.79 £ 3.79 Maplin
DB9 female connector 1 £ 1.49 £ 1.49 Maplin
piezo buzzer 1 £ 0.95 £ 0.95 Proto-Pic
7805 voltage regulator 1 £ 0.99 £ 0.99 Maplin
strip-board 1 £ 3.40 £ 3.40 Farnell
9 V battery connector 1 £ 1.09 £ 1.09 Maplin
9 V battery 1 £ 3.00 £ 3.00 Morrisons
1N4001 diode 1 £ 0.15 £ 0.15 Proto-Pic
100 F capacitor 1 £ 0.24 £ 0.24 Farnell
10 F capacitor 1 £ 0.20 £ 0.20 Farnell
0.1 F capacitor 5 £ 0.15 £ 0.75 Farnell
150 resistor 7 £ 0.10 £ 0.70 Farnell
27 resistor 1 £ 0.10 £ 0.10 Farnell
6 resistor 1 £ 0.10 £ 0.10 Farnell
LM335 temperature sensor 1 £ 0.85 £ 0.85 Farnell
small heatsink 1 £ 0.48 £ 0.48 Farnell
heatsink mounting kit 1 £ 0.15 £ 0.15 Farnell
rca jack 1 £ 0.59 £ 0.59 Proto-Pic
acrylic 1 piece £ - £ - Donated by AbPlas
wire various £ - £ - Maplin
ribbon cable 150 mm £ - £ - Maplin
Total £ 111.45

88
 Bill of Materials: Bottom Controller All prices include VAT
Item Quantity Price each Total Supplier
mbed 1 £ 48.88 £ 48.88 Donated by ARM
IMU board 1 £ 90.00 £ 90.00 Tim Marvin
bolts 4 £ 0.07 £ 0.28 Proto-Pic
nuts 12 £ 0.03 £ 0.36 Proto-Pic
washers 4 £ 0.02 £ 0.08 Proto-Pic
3 junction screw terminal 5 £ 0.25 £ 1.25 Farnell
2 junction screw terminal 4 £ 0.19 £ 0.76 Farnell
2.2 Ah Turnigy LIPO battery 1 £ 10.00 £ 10.00 HobbyKing
MAX3232 IC 1 £ 1.84 £ 1.84 Donated by Exar
20 pin header strip 4 £ 0.59 £ 2.36 Farnell
7805 voltage regulator 1 £ 0.99 £ 0.99 Maplin
strip-board 1 £ 3.40 £ 3.40 Farnell
fuse 1 £ 0.19 £ 0.19 Farnell
fuse holder 1 £ 0.13 £ 0.13 Farnell
200 F capacitor 3 £ 0.26 £ 0.78 Farnell
100 F capacitor 4 £ 0.24 £ 0.96 Farnell
10 F capacitor 1 £ 0.20 £ 0.20 Farnell
0.1 F capacitor 5 £ 0.15 £ 0.75 Farnell
10 nF capacitor 1 £ 0.09 £ 0.09 Farnell
10 K resistor 8 £ 0.10 £ 0.80 Farnell
680 resistor 1 £ 0.10 £ 0.10 Farnell
150 resistor 1 £ 0.10 £ 0.10 Farnell
LM335 temperature sensor 1 £ 0.85 £ 0.85 Farnell
1N4001 diode 6 £ 0.15 £ 0.90 Proto-Pic
RFP30N06LE MOSFET 5 £ 1.12 £ 5.60 Proto-Pic
LMD18200 H-bridge IC 3 £ 17.95 £ 53.85 Farnell
LMD18200 breakout board 3 £ 1.20 £ 3.60 Proto-Pic
small heatsink 6 £ 0.48 £ 2.88 Farnell
large heatsink 3 £ 0.60 £ 1.80 Farnell
heatsink mounting kits 9 £ 0.15 £ 1.35 Farnell
heatsink compound 1 £ 3.69 £ 3.69 Maplin
switch 1 £ 1.79 £ 1.79 Maplin
battery connector 1 £ 0.40 £ 0.40 HobbyKing
terminal block 1 £ 1.28 £ 1.28 B&Q
video camera 1 £ 30.06 £ 30.06 Proto-Pic
microSD card 1 £ 15.99 £ 15.99 Amazon
cable ties numerous £ - £ - B&Q
heatshrink various £ - £ - Farnell
wire various £ - £ - Maplin
Total £ 288.34

89
 Bill of Materials: Hardware All prices include VAT
Item Quantity Price each Total Supplier
piping 4 £ 1.14 £ 4.56 B&Q
corner junction pipe 8 £ 1.09 £ 8.72 B&Q
small T-junction pipe 6 £ 1.30 £ 7.80 B&Q
small c-clamp 7 £ 0.34 £ 2.38 B&Q
large c-clamp 2 £ 0.51 £ 1.02 B&Q
large T-junction 1 £ 12.00 £ 12.00 B&Q
screw end-cap 2 £ 8.99 £ 17.98 B&Q
push-fit end-cap 1 £ 3.99 £ 3.99 B&Q
junction box 1 £ 4.56 £ 4.56 B&Q
screw terminal block 2 £ 1.28 £ 2.56 B&Q
Rule 500 bilge pump 7 £ 12.50 £ 87.50 Borough Bridge Marina
Graupner 5-blade propeller 7 £ 4.77 £ 33.39 gliders.uk.com
screws 14 £ 0.03 £ 0.42 B&Q
nuts 4 £ 0.03 £ 0.12 B&Q
bolts 4 £ 0.07 £ 0.28 B&Q
30 m Ethernet cable 1 £ 10.68 £ 10.68 scan.co.uk
DB9 male connector 1 £ 4.10 £ 4.10 Maplin
cable braid 2 £ 1.91 £ 3.82 Farnell
18-core cable 0.5 m £ 1.62 £ 1.62 Farnell
18 conductor plug and socket 1 £ 36.77 £ 36.77 Northern Connectors
cable grommet 1 £ 3.49 £ 3.49 Maplin
cable holder 1 £ 3.98 £ 3.98 B&Q
polyurethane resin 1 £ 3.15 £ 3.15 Farnell
silicone grease 1 £ 4.49 £ 4.49 Maplin
propeller shaft adapter 7 £ - £ - Donated by U.o.W
acrylic 1 piece £ - £ - Donated by AbPlas
plastic coated wire mesh 400 mm x 300 mm £ - £ - Donated by Jack Bowles
wood-based flotation device various £ - £ - Donated by Jack Bowles
lead weights 4 £ - £ - Donated by Colin Pullen
closed-cell foam various £ - £ - Donated by Colin Pullen
wire various £ - £ - Maplin
electrical tape various £ - £ - B&Q
cable ties numerous £ - £ - B&Q
Total £ 259.38

90
Appendix K - Permissions

Images from Woods Hole Oceanographic Institution:

Email received 9 February 2012:

Hi Scott,

Thank you for your email. You are welcome to use some images from our site in your project report.
Please credit them to Woods Hole Oceanographic Institution.

Best regards,
Erin

Media Relations Office

93 Water Street, MS #16
Woods Hole Oceanographic Institution
(508) 289-3340
[email protected]

Images from VideoRay LLC:

Email received 9 February 2012:

Hi Scott,

You may. Please credit VideoRay LLC in any of the images you use.

Regards,

Brian Luzzi
Marketing Manager
VideoRay LLC

(P) +1 610 458 3015

(C) +1 610 937 6151
(F) +1 610 458 3010
VideoRay LLC
580 Wall Street, Phoenixville, Pennsylvania 19460
www.videoray.com

Schematic and PCB layout from Tim Marvin:

email received 10 April 2012

Scott,

Amazing work man! Of course you can use whatever you need in any way
you need to. Attached are the original .sch and .brd files for Eagle.
If you need PDFs they should be on my project page on the mbed site.
If you need anything else just let me know. I'm happy to help in
whatever way I can. Keep up for great work...I'm always interested in
seeing how it's going.

91
Images from Saab Seaeye:
email received 20 February 2012

Hi Scott,

No problem at all. Please go ahead and use the images.

Best regards

James Douglas
Sales Manager

Mob.Tl: +44 (0) 7766 207 384

Saab Seaeye Ltd

20 Brunel Way
Segensworth East
Fareham
Hampshire
PO15 5SD
United Kingdom
Tel: +44 (0) 1489 898 000
Fax: +44(0) 1489 898 001
Web: www.seaeye.com

Images from SMD Ltd:

email received 20 February 2012

Scott
Thank you for your request.

Please feel free to use our images, however I would appreciate SMD being credited.

Many thanks

Graeme Walker
Sales Manager Trenching & Special Projects

SMD Ltd
Mobile +44(0)7891 260324
www.smd.co.uk

92
Appendix L - Workplan

93
Appendix M - Disk Contents

Report - pdf format

- docx format

Code - top controller

- bottom controller
- data logger code
- MATLAB PID controllers plot file

Pitch and Roll data logging - MATLAB plot files

- logged data files

Schematics and diagrams - top controller schematic

- top controller strip-board
- bottom controller schematic
- bottom controller strip-board
- Tim Marvins IMU schematic
- Tim Marvins IMU PCB layout
Photos

Videos

Noise Analysis - raw data text files

- MATLAB analysis file
- Excel spreadsheets

Bill of materials - Excel spreadsheet

Workplan - Excel spreadsheet

end of report

94