UAV report vFINAL

2014-2015
Cardiff University
School of Engineering
Autonomous ROV
EN4105 UAV Project
Chris Corkill, Chris Powell, David Iddles, Faizan Masood, Ismail Al-Jeffery, Marcus Yap,
Peter Jackson & Stuart Sheath
SUPERVISORS:
Steve Watts (WattsS@cf.ac.uk)
Alastair Clarke (ClarkeA7@cf.ac.uk)
Carlton Byrne (Byrne@cf.ac.uk)

i
Acknowledgements
We would like to thank Steve Watts, Alastair Clarke and Carlton Byrne for their support, guidance
and invaluable feedback throughout the course of the project. Furthermore, technical support from
David Billings, Andrew Rankmore, Richard Rogers and Steve Mead has been very beneficial during
this project. Our appreciation towards these three for taking time away from their responsibilities
to assist us.

ii
Abstract
The aim of the project was to develop an existing submersible Remotely Operated Vehicle (ROV)
for deployment within Cardiff Bay. During deployment, the ROV was required to collect soil
samples from the sea floor and deploy microsensors to measure oxygen concentration and pH
levels. The final design consists of a 3-legged, submersible ROV, equipped with one sediment
sampling mechanism and one microsensor deployment mechanism. A floating buoy facilitates
wireless communication between the ROV and its operator. Control signals are sent from the
operator to the buoy via a Wi-Fi connection then passed to the ROV’s controller via an Ethernet
cable. The same channel is used to send sensor data from the ROV to the operator. The buoy also
supplies power to the ROV’s thrusters via a power cable. The entire system has been found to
operate correctly when tested in a 3.8 m depth, indoor diving pool.

iii
Table of Contents
1. INTRODUCTION...........................................................................................................1
2. 2013/14 UNRESOLVED ROV ISSUES..............................................................................7
3. FULL SYSTEM TEST OF 2013/14 ROV DESIGN..............................................................11
4. 2014/15 CHASSIS MODIFICATIONS ............................................................................12
5. SENSOR DEPLOYMENT SYSTEM .................................................................................17
6. SEDIMENT SAMPLING MECHANISM...........................................................................21
7. DEVELOPMENT OF THE ROV’S CONTROL SYSTEM.......................................................27
8. BUOY ........................................................................................................................38
9. FULL SYSTEM VALIDATION.........................................................................................46
10. FUTURE RECOMMENDATIONS...................................................................................51
11. FINAL SUMMARY ......................................................................................................52
12. REFERENCES..............................................................................................................53
APPENDIX A: BILL OF MATERIALS.....................................................................................55
APPENDIX B: ROV CHASSIS ..............................................................................................56
APPENDIX C: ROV HULLS..................................................................................................58
APPENDIX D: ROV BUOYANCY CALCULATIONS.................................................................60
APPENDIX E: ENLARGED HULL DESIGN .............................................................................61
APPENDIX F: MICROSENSOR DEPLOYMENT MECHANISM DESIGN ....................................63
APPENDIX G: SEDIMENT SAMPLING MECHANISM DESIGN ...............................................82
APPENDIX H: BUOY DESIGN.............................................................................................89
APPENDIX I: TETHER MANAGEMENT SYSTEM DESIGN......................................................93
APPENDIX J ELECTRICAL SCHEMATICS..............................................................................97
APPENDIX K: DETAILED SOFTWARE INFORMATION........................................................ 100
APPENDIX L: THRUSTER BATTERY SPECIFICATION .......................................................... 121
APPENDIX M: LIST OF USER COMMANDS....................................................................... 124

1
1. Introduction
1.1. Project Brief
The ROV is to be used by Cardiff University’s Earth and Ocean Sciences Department (EOSD) for
exploration and data collection in Cardiff Bay. After discussions with the EOSD at the beginning of
the 2014/15 academic year, the following ROV specifications were agreed upon:
 A manageable size and weight for the ROV
 A mission duration of 15-45 minutes
 A mission radius of 50-200 metres
 An operating depth of up to 20 metres and temperature 4-25 degrees Celsius
 Ability to acquire a sediment sample from the seabed.
 Ability to deploy a Unisense Microsensor (Unisense, 2015) into the seabed.
1.2. Budget
A budget of £2000 was provided for further development and completion of the existing design.
Of this amount, £1793.72 was spent. The full bill of materials for the ROV, including each
component referenced within this report, can be found in Appendix A: Bill of Materials.
1.3. Previously Completed Work and its Limitations
The UAV ROV project was started in the 2013/14 academic year and is now in its second year of
development. As such, a ROV had already been designed and constructed prior to the beginning
of the 2014/15 academic year, details of which are provided by Bentley et al (2014). It was decided
to further develop this existing ROV to achieve the aforementioned specification.
Because of time restrictions encountered in the previous academic year a number of issues
associated with the ROV had remained unresolved. The most critical of these issues was the

2
waterproofness of the hulls that housed the electronic components. It had been discovered that
the cable glands originally installed did not prevent water from entering the hulls. Additional
inspections performed at the beginning of this academic year highlighted the poor condition of
the O-rings used to create a seal between the hull body and its end-caps. It was found that pinching
of the O-rings would occur when inserting the end-caps. This was due to over-sized O-rings being
used as well as incorrect dimensions of the glands they sat in.
Another outstanding issue was the state of the ROV’s control system. Because of the leaking cable
glands, the control system designed during the previous year had not been validated.
Furthermore, the main hardware components had been disconnected and there was no
information available to indicate how they were wired originally. It was also discovered that three
thruster controllers and the batteries used as the main power supply had been broken, and as
such were no longer usable. In addition, the battery used to power the National Instruments
myRIO was missing.
Finally, the LabVIEW program written to accompany the hardware was undocumented and had
vital sections of code missing. Without this code or the documentation necessary to replicate it,
controlling the ROV as it was originally intended was not possible.
All of these issues needed to be resolved before development of the ROV could commence.
1.4. Group Management
Eight individuals were involved in the project. Because of the need to resolve the outstanding
issues outlined in Section 1.3, this group was initially divided into two smaller groups of four. The

3
first group focused on resolving the outstanding issues whilst the second group investigated ways
in which the ROV could be modified to achieve the specification.
Table 1 summarises the actions completed by the first group to resolve the outstanding issues. In
depth detail of each action can be found in the report section indicated.
Table 1: Actions taken to resolve the outstanding issues outlined in Section 1.3.
Action
Report
Section
Replacement cable glands ordered and fitted. 2.1
Inside edges of both hulls chamfered. 2.1
114 mm ID O-rings ordered and fitted to end-caps to replace the original 118 mm ID
O-rings.
2.1
Silicon grease ordered and applied liberally to both end-cap and cable gland seals. 2.1
Control system hardware understood and rewired. 2.2
Broken thruster controllers replaced with new controllers. 2.3
New myRIO battery purchased. 2.4
New control program written using LabVIEW allowing the ROV’s motion to be
controlled in the horizontal plane.
2.5
Test performed in Maindy swimming pool to validate ROV waterproofness and
control system.
3
The outcome of the second group’s investigation was the identification of a number of necessary
ROV modifications. These are listed in Table 2.

4
Table 2: Modifications performed on the ROV during the 2014/15 academic year.
Category Modification
Report
Section
ROV Hardware
& Chassis
Revalidation of hulls to account for increased operating
depth.
4.2
Modification of end-caps to enable the addition of a larger
number of cable glands as well as an easily accessible battery
charging point.
4.3
Re-design and manufacture of hardware fastenings within
each hull.
4.4
Distribution of additional weight to prevent unwanted pitch
or roll.
4.4
Addition of legs and feet to chassis. 4.5
Sensor &
Sampling
System
Hardware
Design and construction of a micro-sensor deployment
mechanism.
5
Design and construction of a sediment sampling mechanism. 6
Control Systems
&
Communication
Expansion of the control system to incorporate the electrical
hardware associated with the microsensor deployment
mechanism.
7.2.1
Expansion of the control system to incorporate the electrical
hardware associated with the sediment sampling mechanism.
7.2.2
Implementation of wireless communication between the user
PC and ROV.
7.2.3
Expansion of the control system to incorporate a spot light to
increase camera visibility.
7.2.6
Further expansion of the control program to facilitate the
deployment of micro-sensors and sediment sampler.
7.5.1
Rewrite of the control program to allow all ROV actions to be
easily controlled from a remote PC, as well as to acquire data
from the ROV’s sensors.
7.5.1
Design and implementation of an intuitive user interface. 7.5.2
Buoy Hardware
& Chassis
Design and construction of a waterproof compartment. 8.1
Design and construction of a buoy chassis. 8.1
Design and implementation of a tether management system. 8.4

5
It can be seen how these modifications were split into four categories. Once the actions listed in
Table 2 had been completed four new groups were formed. Each group was then tasked with
implementing all the modifications in one of the four categories. Figure 1 shows how tasks were
divided within the group.
Figure 1: Division of work within the group.
It must be noted that each group did not operate independently as the decisions of one would
almost certainly affect the decisions of the other three. As such, continuous collaboration between
each group was key to the project’s success. Weekly meetings were held to discuss direction and
progress, with targets set to manage time and effort. Meeting minutes were recorded regularly
which served as written record and were archived for reference.
1.5. System Overview
The entire system design, illustrated by Figure 2 and Figure 3, consists of a submersible ROV with
one sediment sampling mechanism and one microsensor deployment mechanism. A buoy is used
to facilitate wireless communication between the operator and the ROV, as well as to provide
power to the ROV’s thrusters.
UAV ROV
Control Systems &
Communication
Buoy Hardware
& Chassis
Sensors & Sampling
System Hardware
ROV Hardware &
Chassis

6
Figure 2: System overview.
Figure 3: Models of the sediment sampling mechanism (1), microsensor deployment mechanism (2) and buoy (3).

7
2. 2013/14 Unresolved ROV Issues
There were a number of issues with the existing ROV design, identified during the 2013/14
academic year, which had prevented a full system test of the ROV. Further issues were also
discovered when an inspection of the ROV was performed at the beginning of this academic year.
It was decided that performing a full system test would be the first objective of this academic year,
hence it was necessary to resolve all of these issues, summarised in Table 3.
Table 3: Summary of all the issues that required resolution.
Issue No. Description
1 Water ingress into hulls used to house electronic components.
2 All electronic hardware disconnected.
3
Batteries used to power thrusters damaged.
Three of five thruster controllers damaged.
4 Battery used to power myRIO missing.
5 Existing control program incomplete.
2.1. Water Ingress into Hulls
It had been shown that the cable glands fitted to each end cap did not prevent water ingress into
the hull. Alternative cable gland options were therefore researched. Legrand Cable Glands (PG9,
4-8mm), were found to be the most suitable replacement.

8
It was also noticed that the O-rings used to create a
seal between the end-cap and the main body of the
hull had been damaged. It was concluded that the
inner diameter of the O-rings was too large which
regularly caused the O-rings to be pinched between
the end-cap and hull body when inserting the end-cap,
as shown in Figure 4.
It was also found that the glands in which each O-ring
sat were not wide enough to allow for compression of
the O-rings. This further increased the occurrence of pinching. It was necessary to prevent this
pinching as continued damage to the O-rings would result in their eventual failure.
Replacement O-rings were sourced with a smaller inner diameter of 114 mm. These smaller O-
rings effectively eliminated the occurrence of pinching. As an extra precaution, the inner edges of
the hull bodies were chamfered to limit any damaged caused if pinching were to occur. The O-ring
glands were also redesigned in accordance with BS ISO 3601-2:2008 (2008), however it was
advised that the modifications would be difficult to implement. Since the pinching problem had
been effectively resolved with the smaller O-rings it was decided not to implement the gland
changes. As a reference for any future end-cap design, drawings of the planned O-ring gland
modifications can be found on the accompanying CD.
Silicon grease was also applied liberally to all sealing surfaces to further increase the
waterproofness of the hulls.
Figure 4: Example of pinching that occurred as a
result of oversized O-rings.

9
2.2. Disconnected Electronic Hardware
All electrical connections between the main components of the control system had been removed
prior to the beginning of this academic year. Reconnection was clearly necessary if the ROV’s
control system was to be tested. Whilst the task of reconnecting the hardware was not a complex
task, the lack of informative documentation resulted in a large amount of time being spent
ensuring each connection was correct. Further time and budget was spent sourcing the wiring and
fastenings required to implement the connections.
2.3. Damaged Thruster Batteries and Controllers
All four batteries used to power the ROV’s thrusters had been damaged at the end of the 2013/14
academic year and were no longer usable. A replacement power supply was therefore required to
perform the test. Because of the planned ROV developments it was not yet known whether the
original battery capacity would need to be increased. As such, it was decided not to order
replacement batteries at this stage in case these also needed replacing further into the project.
A desktop power supply was sourced from the electrical technicians’ workshop at the University.
This was able to produce the required voltage of 22.2 V with a maximum current of 10 A. The
power supply would be remote from the ROV, with a length of cable transferring power between
the two. Because each thruster was expected to draw about 4 A continually at maximum power,
it was only possible to have two thrusters active at any one time. Since the ROV design required
two thrusters to be active when moving horizontally, the first full system test in Maindy pool did
not include the fifth vertical thruster.

10
Three of the five thruster controllers had also been damaged and were no longer responding to
commands. Spare components from the previous academic year included one controller,
therefore two more controllers were purchased.
2.4. Missing myRIO Battery
The whereabouts of the battery used to power the myRIO was unknown at the beginning of this
academic year. A replacement Turnigy, 11.1 V, 2200 mAh, LiPo battery was therefore purchased.
The specification of the battery was based upon the calculations shown in Appendix L.
2.5. Incomplete Control Program
Files containing the control program written in the 2013/14 academic year were provided,
however a number of critical files were incomplete or missing. It was decided that completely
rewriting the program for the test was the best course of action for two reasons. Firstly, it was
agreed that the method the original program used to control the ROV’s motion could be improved
upon. Secondly, it was anticipated that the majority of the program would need to be rewritten at
some point in order to meet this year’s specification.
Once rewritten, the program used for the test enabled the user to move the ROV in the horizontal
plane, either forwards, backwards, sideways, clockwise or anticlockwise, using the PC keyboard.
The program also displayed the ROV’s bearing and streamed real-time video images to the user
PC. These images could then be saved as video files or photos on the PC's hard drive.

11
3. Full System Test of 2013/14 ROV Design
Because of the issues described in Section 2, a full system test of the ROV’s systems was not
performed in the 2013/14 academic year. A full system test was therefore the first objective of
this academic year.
3.1. Objectives of Test
The objectives of the test were as follows:
 Correction of any observed roll or pitch imbalances.
 Assessment of the ROV’s manoeuvrability.
 Comparison of the ROV’s horizontal and rotational velocities with the velocities predicted
by the CFD analysis performed in the 2013/14 academic year.
 Assessment of the camera’s visibility under water.
 Identification of any other unforeseen problems in a practical setting.
3.2. Test Results
With an equal mass in each hull the ROV sat level in the water without any significant pitch or roll.
The same was also true when the ROV was in motion.
When moving in a straight line the ROV had a tendency to drift left or right. This appeared to be
caused by a drag force from the power and Ethernet cable.
The ROV had an average maximum velocity of approximately 0.45 m/s when moving either
forwards, backwards or sideways. This was just over half of the 0.8 m/s predicted by the CFD
analysis. It had a maximum angular velocity of approximately 1.6 rad/s when rotating clockwise or
anti-clockwise but predictions for this had not been provided by CFD analysis.

12
In clean pool water the camera had a range of visibility of approximately 15 m.
A significant delay was observed between the motion commands input at the PC and the
subsequent activation of the ROV’s thrusters. This also meant that the two thrusters in operation
did not activate at the same time, causing the ROV to rotate about its vertical axis. It was suggested
that this was due to the large amounts of data being transferred between the ROV and the PC, a
result of the high resolution and frame-rate image stream. It was decided to reduce this delay in
future tests by reducing the image quality as well as utilising more efficient data transfer protocols.
4. Chassis Developments
4.1. Shape of ROV
The existing ROV design did not leave much room for the addition of any sampling equipment. The
sensors being used could only be deployed vertically which was extremely difficult with the current
design. These specific requirements meant that the design needed to shift to a Benthic Lander
shape form for the ROV. Such a design has been displayed below in Figure 5, to give an idea of
how sensors are deployed vertically from a stable position.
1) Benthic Lander (Unisense 2015) 2) 2013/14 Design 3) 2014/15 Final design
Figure 5: ROV chassis modification based upon a Benthic Lander design.

13
Legs were added to the ROV, in a tripod arrangement to maximise stability at the slight expense
of overall manoeuvrability. Polycarbonate feet were added to allow for a larger surface area over
which to spread the weight of the ROV, to avoid sinking into the soft mud found on the seabed of
Cardiff Bay. The feet were made of clear polycarbonate sheets because it was lightweight and in
line with the aesthetics of the overall design.
Sampling equipment was to be attached to each leg to allow vertical deployment as required.
Figure 5 shows how the chassis base was made wider, with the quarter round sections of the
chassis (red) being replaced by regular square sections (green) to facilitate the attachment of the
legs.
ROV buoyancy calculations are provided in Appendix D: ROV Buoyancy calculations.
4.2. Hull Pressure Rating
The specification for ROV working depth changed this year from 15 m to 20 m. Hand calculations
were performed to prove that current 3 mm hulls are capable of working up to a 20 m depth with
a safety factor of 2. It was assumed that the polycarbonate had a maximum yield stress of 10MPa,
as specified on the datasheet which can be found on the accompanying CD. FEA analysis was also
performed using Patran®. Detailed results of this analysis can be found in Appendix C: ROV Hulls.
4.3. End-Cap Modifications
The addition of the sediment sampling and micro-sensor deployment mechanisms to the ROV
required additional cable entry points into both hulls. It was also anticipated that future ROV
developments would require additional cable entry points. It was therefore decided to modify
each end-cap to accommodate as many entry points as possible. Figure 6 illustrates the end-cap

14
labelling system. End-caps 2, 3 and 4 all had four existing entry points, hence it was not practical
to add any more. It was however possible to add four entry points to end-cap 1.
It was also necessary to attach a Bulgin
PXP7012/06S/ST connector to one end-cap in
order to enable easy access to the myRIO battery
as discussed in Section 7.2.5. End-cap 3 was
therefore modified to accommodate the Bulgin
connector.
Technical drawings detailing the end-cap
modifications are provided on the CD.
4.4. Hull Interior Modifications
Due to a large array of electronics being used within the ROV, an interior re-design was necessary
to ensure that space was being used effectively and that all the components were fixed securely;
especially, with the onset of further hardware this year.
The original location of all four thruster batteries, each weighing 0.57 kg, in one of the ROV’s
waterproof hulls placed a considerable constraint on their size, which in turn limited their total
capacity. 3D printed holders were designed to hold the batteries but weight distribution wasn’t
given much consideration. There was a significant weight difference between hulls, which caused
the ROV to tip drastically in the direction of the heavier hull.
Figure 6: End-cap labelling system.

15
The location of all electronics within one hull
meant securing each component was difficult
due to limited space. Figure 7 shows this
haphazard arrangement and illustrates the risk
of damage to components that this poses.
In order to alleviate size constraints, as well as to create more space for additional hardware, the
thruster batteries were relocated to the buoy. This freed up one of the hulls and allowed
components to be distributed between the two hulls, correcting weight issues. Each component
was positioned such that each wired connection was as short as possible. 3D printed parts were
then designed to hold each component in its place securely. Table 4 below, highlights the final
position of each electronic component within the two hulls. The hulls were labelled A and B at this
point for clarity and will be referred to this way hereafter in the report. Hull A is the one which
situates the myRIO.
Table 4: Distribution of components between each hull.
Hull A Hull B
myRIO Thruster Motor Controllers
myRIO battery (11.1V) Depth Sensor
Camera and LED spotlight Battery for Servo (7.4V)
Stepper Motor Controller PCB B
Ethernet Adapter
USB Hub
PCB A
Figure 7: Exisitng hull shows haphazard arrangement

16
4.5. ROV Legs and feet
The ROV legs shown to the top right in Figure 8 had to go
through a number of design iterations before settling into
their final design. Details for the design process have been
provided in Appendix B: ROV Chassis. The final design of
three vertical legs was determined by the choice of
mechanism employed for the sensors and sediment sampler.
Due to the method of attaching the legs to the chassis,
aluminium plate reinforcement was necessary to prevent
the legs from twisting out of place. The sensor assembly
(red) was quite straightforward with two brackets connecting the leg to the sensor assembly. The
sediment sampler assembly (green) employed a pair of servos that needed to be mounted to the
side of the leg. For this purpose, appropriate parts were used to provide the necessary attachment
to the leg. Holes were machined in the foot plate to allow the microsensor and sediment sampler
to penetrate the seabed.
Figure 8: Final leg assembly.

17
5. Sensor Deployment System
The customer specification stated that they wished to investigate carbon flux in and out of the sea
bed by using Unisense microsensors to take oxygen and pH readings. The task was to design a
system to deploy these sensors and protect them during the mission.
Two types of microsensor needed to be deployed; an O2 MicroOptode and a pH microelectrode.
The MicroOptode uses glass fibres to measure oxygen concentrations. These would normally be
protected inside a steel needle. The sensor would be inserted into the sample and then the glass
fibres would be pushed out of the end by a button on top of the sensor. The sensor was designed
to be operated by hand. It was soon found that this would be difficult to achieve. It was agreed
with the customer that, as the amount of fibre protruding from the needle could be adjusted, the
fibre would be locked in place with the tip of the fibre just beyond the tip of the needle.
The pH microelectrode required a reference electrode to be deployed at the same time to take
readings. This meant that three sensors would be needed for two measurements. The sensors
were all approximately 170mm in length and had at least 60mm of cylindrical plastic casing at the
top meaning a single system could be designed to accommodate any of the sensors.
Photos of all the microsensors are provided in Appendix F: Microsensor Deployment Mechanism
Design.

18
5.1. Final Design
A number of designs were considered for the deployment of the
microsensors. These have been explained in detail in Appendix F:
Microsensor Deployment Mechanism Design. In the end, it was
decided that stepper motors with leadscrews would be used for the
system as they are light, compact and produce linear motion directly.
The final design for the system, with 3D printed securing brackets, is
shown in Figure 9.
5.1.1. Stepper Motor and Controller
As stated above, a stepper motor was used for linear motion. It offers a precise positioning and
repeatability of movement, where all movement errors are non-cumulative between steps,
justifying its appointment due to the sensitive sensor equipment. The stepper motor will be
powered through the motor controller, of which is directly powered from the battery within one
of the hulls.
A Unipolar motor controller has been chosen for the movement of the stepper motor used for the
sensor deployment. The controller provides the ability to control of four separate stepper motors,
so includes the operation of the three Unisense sensors on board as well as the capability of a
fourth stepper motor for other future purposes.
The initial control program design controlled the stepper motors using the Phidget controller by
running a C++ library function through the myRIO. This was done through the myRIO by creating
a VI that calls a library with a “Call library function node” that will read and run a shared library
Figure 9: Final deployment
system design.

19
stored locally on the myRIO. The function runs a program in which moves each motor to the
sediment level for measurement, and will wait for user input before it will retract the sensors back
into the holding system. Appendix F: Microsensor Deployment Mechanism Design provides further
details.
5.1.2. Structure and Waterproofing
The casing for the system comprises of; 3 polycarbonate cylinders of varying diameters, two
polycarbonate end caps and a plunger. It was designed to be disassembled to access the sensor
and the motor. The stepper motor was secured to the top face of the lower end cap. A hull, tall
enough to accommodate the leadscrew, was made from a polycarbonate cylinder with two end
caps. O-rings were used to seal the end caps. The leadscrew went through the lower end cap and
attached to a 25mm diameter polycarbonate plunger which was encased in a 26mm diameter
polycarbonate tube. The plunger was machined to fit a pair
of O-rings which would seal the gap between the plunger
and the tube as shown in Figure 10. Further details including
calculations can be found in Appendix F: Microsensor
Deployment Mechanism Design. A 3D printed holder glued
to the plunger secured the microsensor. The last tube was
added as a protective cover for the sensor.
5.2. Unisense Data-Loggers
A miscommunication with the customer meant that it was initially decided to amplify the signal
from the sensors and store the data on the myRIO. It was eventually discovered that the data from
the sensors had to be sent straight to specific Unisense data-loggers otherwise it would be invalid
Figure 10: Plunger with O-rings.

20
to use in a scientific journal. The data-loggers both amplified and stored the data. This meant that
they had to be on board the ROV as the signal from the sensors was so weak, pico-Amps in the
case of the pH sensor, that it would not reach the surface through 20 metres of cable. The data-
loggers were extremely expensive so would not be available for this project. They were also quite
large compared to the other ROV components. It was therefore decided that the current hulls
would not be modified but new, larger hulls would be designed for future projects. Models and
drawings for the new hulls can be found in Appendix F: Microsensor Deployment Mechanism
Design.
5.3. System Limitations
Testing of the stepper motor showed that while it could easily move the plunger with one O-ring,
two O-rings provided too much friction and the motor was not powerful enough. Waterproof tests
showed that one O-ring around the plunger was sufficient but time limitations prevented
extensive underwater testing.
The O-rings used to seal the plunger were Nitrile O-rings and these were lubricated and given extra
sealant with silicon grease. However over time silicon grease becomes sticky and less effective. A
solution could be to use Viton O-rings. These are more expensive, however they slide much more
easily and do need lubricant such as silicon grease. This could make them a better option to seal
the plunger.
Issues were encountered when transferring the completed program to the myRIO and time
constraints prevented a full validation of the microsensor deployment system.

21
6. Sediment Sampling Mechanism
In order to further analyse the results of the Unisense microsensors, the customer required a
system to store and collect a small amount of sediment for testing. Test samples are the easiest
and best way to conduct more detailed and sophisticated tests in the lab. The location of the
sample must be relative to the location of the microsensor deployment therefore the system had
to be assembled close to the microsensor assembly. The customer also specified the need to keep
the sample undisturbed and preferably with its layer intact. For this reason a bespoke soil sampling
system has been developed to meet the requirements of the customer. Due to the complexity of
the problem and the added burden of waterproofing the whole arrangement, the final solution
was reached after a rigorous iteration process. Details of the iteration process is provided in
Appendix G: Sediment Sampling Mechanism Design.
6.1. Chosen System
Deep-sea divers typically collect samples via a syringe capsule by hand. This method was
investigated to see if the syringe could operate remotely. Environmental Sampling Supply ©
produce a LOCK N’ LOAD syringe shown in Figure 11 (Environmental Sampling Supply, 2015) which
was deemed appropriate for the task.

22
Capsules are cheap and designed to collect
sediment, with a bevelled syringe to allow for
easy insertion and incorporated plunger that
creates a vacuum to hold sample inside the
syringe. It was decided that the syringe
method offered a simple, cheap and non-
intrusive solution; the next step moving
forward would be designing the actuation
system for the syringe.
6.2. Testing of Sampling Syringe
Before deciding on any actuation system, the method in which the ESS syringes are used needed
to be studied and tested. Since the syringes are typically meant to be used by hand, the first test
was to establish how effective they were when collecting the required type of sediment. Figure 11
shows the blueprints of the syringe provided by ESS, it can be seen that that within the syringe
body is a plunger that slides up when inserted whilst creating a vacuum. This is highly significant
as the syringe was most effective when it was sucking up i.e. when the plunger was fixed and the
body free to move linearly.
Figure 12 and Figure 13 illustrate the experimental setup that was utilised, the plunger was fixed
while the body was free to move into the mud sample, weights were added to approximate the
required force needed. From the test, it was established that the plunger needed to be fixed and
the force required to insert and withdraw the syringe body was calculated to be 20N-30N.
Figure 11: Blueprints of LOCK N’ LOAD Soil Sampling
Syringe

23
Figure 12 Experimental setup of force test
Figure 13: Syringe under 10N and 20N respectively

24
6.3. Final Design
After a rigorous iteration process a final design was reached using
dual servos as shown in Figure 14. Appendix G: Sediment
Sampling Mechanism Design discusses the preliminary designs
involved before deciding on this one. These include testing and
evaluating with the customer different design solutions in order
to come up with the most feasible, cost effective solution
possible, whilst being considerate to any physical impact it could
have on the design of the ROV.
The servo used is a high torque, Hitec HS7954SH-G2 Servo. A high
amount of torque is required to rotate a link arm. The link arm
needed to be extremely rigid to prevent any torsional effects as
well as be able to resist any damage due to constant salt water
contact. As such, a 10 cm, high density plastic sail arm was
sourced. The length of the link arm is important in order for the syringe to reach the required
insertion depth, Figure 15 illustrates this further.
As you can see from Figure 15, assuming a max insertion depth of 3.5 cm and angle of rotation of
45˚, the servo must be at least 3.5 cm away the contact point of the slider. This means when the
syringe is fully inserted into the seabed, the length of the arm must be at least 4.9 cm.
Figure 14: Final design of sediment
sampling system.

25
The relationship between the servo torque, the force on the syringe and horizontal distance
between the servo and the syringe is given by the following equation:
𝐹𝑜𝑟𝑐𝑒 (𝑁) =
𝑇𝑜𝑟𝑞𝑢𝑒 (𝑘𝑔. 𝑐𝑚)
𝐷𝑖𝑠𝑡𝑎𝑛𝑐𝑒 (𝑐𝑚)
We were able to determine the minimum amount of force the servo could exert on the syringe.
Since the max length of the arm is 10cm and the max torque is 22kg.cm, it was worked out that
the minimum force would be 21.6N, which is within the 20N-30N requirement for an effective
yield.
After a sample is taken, the syringe still needs to be capped to prevent the sample from escaping
when the ROV is moving. Therefore a cap has been designed to allow easy capping of the syringe
following the collection of a sample. A bowl design has been developed where the base on which
the syringe rests has a smaller diameter compared to the mouth. This way, the syringe has a bigger
target and capping is made easier where the syringe can slide in to sit on the base. This prevents
Figure 15: Trigonometric illustration of link arm length in relation to slider.

26
any soil from being washed away after collection thus preventing disturbance of the sample. The
cap will be placed on a link arm operated by a secondary less powerful servo. This servo forms part
of the capping mechanism for the syringe assembly. A number of design ideas were considered
for use here but in the end, a standard low torque servo proved to be the simplest and most cost
effective solution. The servo is attached to the side of the leg and rotates the cap in place to allow
the syringe to lower into position as shown in Figure 16.
6.3.1. Waterproofing
The servos were water proofed by first coating the circuit board and motor in a non-conductive
silicone gel. Secondly, the servo was filled with non-conductive, low viscosity vegetable oil making
sure each servo is fully submerged in the oil when assembled. This prevents water ingression into
the servo through the seams and screw openings. An O-ring was placed around the servo head to
stop oil from escaping. Finally, the outside housing was coated in a liquid epoxy that is resistant to
water and is insulating.
Figure 16: Plan view of capping servo.

27
7. Control System Developments
Based upon the specification outlined in Section 1.1 it was necessary for the ROV’s control system
to provide the following functionality:
1) Enable all ROV actions to be controlled wirelessly by the user from a PC.
2) Facilitate the deployment of the micro-sensor mechanism.
3) Facilitate the deployment of the sediment sampling mechanism.
4) Enable the motion of the ROV to be controlled easily and intuitively.
5) Real-time streaming of video from the ROV to the user PC.
6) Ability to record video and capture photos.
7) Sufficient battery capacity for a 45 minute mission duration.
8) Enable the ROV power supply to be easily connected and disconnected.
9) Enable the ROV power supply to be easily recharged.
In order to achieve these aims the control system’s hardware and software both required
modification.

28
7.1. Review of Existing Control System Hardware
Figure 17 is a basic layout of the control system that was developed during the 2013/14 academic
year.
It was found that the desired level of motion control could be achieved by utilising the existing
sensors and thruster controllers. The camera was also found to be sufficient for the streaming and
recording of video and images.
In order to deploy the micro-sensor mechanism, a stepper motor and controller needed to be
added to the control system. Likewise, two servo motors needed to be added to enable the
deployment of the sediment sampling mechanism.
Figure 17: Basic layout of control system developed during the 2013/14 academic year.

29
The requirement of wireless communication between the ROV and its user proved to be a
significant constraint due to the complexities associated with transferring data wirelessly through
water. It was decided that the most effective way of enabling wireless communication was to
position a Wi-Fi router on the surface of the water and connecting it to the myRIO in the ROV via
an Ethernet cable and USB-Ethernet adaptor. This allowed data to be sent from the myRIO to the
router via a wired connection, then from the router to the user PC via a wireless connection, and
vice versa. It was thus decided that along with the thruster batteries, the buoy would also
accommodate a Wi-Fi router. The design of this buoy is detailed in Section 8.
Considerable disassembly of the ROV was necessary to disconnect and reconnect the batteries in
the original control system. This proved to be a major limitation when attempting to connect or
disconnect the ROV’s power supplies in the field. Relocating the thruster batteries to an easily
accessible position on the buoy remedied part of this problem however modifications still needed
to be made to the ROV to enable easy access to the myRIO battery.
7.2. Implementation of Hardware Modifications
7.2.1. Micro-Sensor Deployment Hardware
The micro-sensor deployment mechanism utilises a Portescap 35DBM10B2U-L stepper motor and
a Phidget Stepper Unipolar Motor Controller is used to power the stepper motors whilst also acting
as an interface between the stepper motor and the myRIO. The Phidget controller is in turn
powered by the same battery used to power the myRIO. A USB connection is used to pass
commands from the myRIO to the Phidget controller via the USB hub. The Phidget controller
converts these commands into signals which are then sent to the stepper motor.

30
7.2.2. Sediment Sampling Hardware
A Futaba S3003 servo motor is used to manoeuvre the cap of the sediment sampler. This servo
motor is powered and controlled directly by the myRIO. The red, white and black wires of the
servo motor are connected to the +5V, PWM0 and DGND (MXP A) pins of the myRIO respectively.
A Hitec HS-7954SH servo motor is used to manoeuvre the syringe of the sediment sampler in the
vertical direction. The power requirement for this servo motor was too large for it to be powered
by the myRIO directly and its input voltage of +7.4V was not within range of both the myRIO
battery and the thruster batteries. As such, a separate Storm 7.4 V, 1800 mAh, LiPo battery is used
to power the servo motor. The positive lead from this battery connected to the red lead of the
servo motor, whilst the negative output lead from the battery is connected to the DGND (MXP A)
pin of the myRIO together with the black lead of the servo motor. The yellow lead of the servo
motor is connected to the PWM1 (MXP A) of the myRIO.
7.2.3. Wireless Communication
An Edimax Wireless Router with 4 LAN ports and a maximum connection speed of up to 300 Mbps
was used to facilitate wireless communication. Power is provided to the router from a 2200 mAh
portable charger power bank. An Ethernet cable 25 m in length connects the LAN1 port of the
router to the USB-Ethernet adaptor connected to the myRIO. Once the router has powered up the
name of the router’s Wi-Fi network appears as the available network connection “UAV Submarine”
on the user PC. Selecting this network and then entering the password “esub2015” when
prompted sets up communication between the user PC and the ROV.
A USB antenna was supplied by the University with the aim of extending the signal range of the
user PC if necessary.

31
7.2.4. Thruster Batteries
Four Turnigy, 5000 mAh, 22.2 V, LiPo batteries were connected in parallel and used to supply
power to all five thrusters and their controllers. It was estimated that the combined capacity of
the four batteries would be sufficient to operate three thrusters at full power for a duration of 90
minutes. Calculations supporting this estimation are contained in Appendix L. A length of 25 m,
1.5 mm2, 3 core power cable transferred power from the batteries located on the buoy to the
thruster controllers on the ROV.
7.2.5. Easy Access to the myRIO Battery
It was decided that it should be possible to
connect, disconnect and recharge the
myRIO battery without having to
disassemble the ROV. To achieve this, the
power and balance leads were routed to a
Bulgin PXP7012/06S/ST connector which is
attached to one of the hull end-caps as
shown in Figure 18. Also routed to the connector were the positive and negative leads from the
myRIO, spot light (see Section 7.2.6) and stepper motor controller power inputs.
Figure 18: Connecting the battery to the myRIO via the
Bulgin® connector.

32
When deploying the ROV, a mating Bulgin
PXP7010/06P/ST connector is attached as shown
in Figure 19. Figure 19 also illustrates how the
terminals of this connector are wired together,
completing the circuit between the battery and
the myRIO, spotlight and stepper motor
controller. In order to seal the electrical connections, one end of a dummy cable has been inserted
into the rear of the Bulgin connector and the other end into a spare cable gland on the end-cap.
When the battery requires charging, the Bulgin connector is detached then a second Bulgin
PXP7010/06P/ST connector is attached. This second connector routes the battery’s power and
balance leads to the charging station as shown by Figure 20.
Figure 20: Connecting the battery to the charging station via the Bulgin® connector.
7.2.6. Additional Hardware Modifications
A 4.5 W LED spot light was positioned next to the camera to increase its visibility in low light. Its
power was supplied from the myRIO battery via a switching circuit (PCB C). The switching circuit
was designed to connect or disconnect the power supply to the spot light in response to a high or
Figure 19: Attachment of mating Bulgin connector.

33
low signal from the myRIO respectively. A schematic of the switching circuit is provided in
Appendix J: Electrical Schematics. The black and red leads of the switching circuit are connected
to the negative and positive terminals of the myRIO battery respectively. The green and
green/black wires of the switching circuit are connected to the DIO0 and DGND (MXP B) pins of
the myRIO respectively. The brown and blue wires of the switching circuit are connected to the
terminals of the spot light.
A 6 A fuse was positioned between each thruster and its respective controller. This ensured the
current supplied to an individual thruster could not significantly exceed its maximum rating of 5.8
A.
A 20 A fuse was positioned between the thruster batteries and thruster controllers to prevent
excessive current from being drawn through the power cable. This also limited the maximum
number of thrusters that could be active at any one point in time to three.
A 1.5 A fuse was positioned between the myRIO battery and the myRIO power input. This ensured
the current supplied to the myRIO could not exceed its maximum rating of 1.5 A.

34
7.3. Summary of Hardware Modifications
Figure 21 details all of the implemented hardware modifications. A larger copy of Figure 21 is
provided in Appendix J: Electrical Schematics. Schematics of PCBs A, B and C are also provided in
Appendix J: Electrical Schematics.
7.4. Review of Existing Control Program
As mentioned in Section 2.5, a control program had been written using LabVIEW during the
2013/14 academic year. It was agreed that the method by which this program controlled the
motion of the ROV had room for improvement. In addition to this, a number of critical program
files were found to be missing. As such, it was decided that developing a new control program
would be the best course of action. Not only did this allow a more intuitive motion control strategy
to be implemented, it also allowed additional program functions, such as micro-sensor and
sediment sampler deployment, to be more easily integrated into the control program.
Figure 21: Schematic of the ROV’s control system hardware after modifications.

35
7.5. Summary of New Control Program
The aim of the control program was to coordinate the actions of each hardware component on
board the ROV in order to achieve the objectives outlined at the beginning of this section. The
control program was written in LabVIEW and comprised two main VI’s (User panels) which are
executed simultaneously. The first main VI, referred to as the host VI, is executed on the user PC
whilst the second main VI, also referred to as the target VI, is executed on the myRIO. The functions
performed by the host VI are:
 Acquirement of user commands via a keyboard, mouse or an Xbox control pad.
 Interpretation of user commands and communication of these to the target VI.
 Acquirement of sensor data communicated by the target VI.
 Interpretation of sensor data and communication of relevant information to the user via a
visual user interface.
The functions performed by the target VI are:
 Acquirement of user commands communicated by the host VI.
 Interpretation of user commands followed by sending of appropriate control signals to
relevant hardware components.
 Acquirement of data from the on-board sensors and its communication to the host VI.
Figure 22 illustrates the types of information acquired by both the host and target Vis, as well as
the resulting outputs.

36
Figure 22: Graphical representation of the inputs and outputs of both the host and target VIs.
Detailed descriptions of the communication protocols adopted and the algorithms executed
within the host and target VIs are provided in Appendix K: Detailed Software Information.
7.5.1. User Commands
User commands can be inputted via a keyboard, Xbox control pad or mouse. Key assignments are
provided in Appendix M: List of User Commands.
7.5.2. Visual User Interface
Figure 23 displays the user interface.
Figure 23: Visual user interface.

37
Table 5 details the key features of the user interface labelled in Figure 23.
Table 5: Description of user interface features.
Feature Description
01 Depth gauge with depth limit exceeded warning light.
02 Compass with ACW and CW rotation limit exceeded warning
lights.
03 Video display.
04 Micro-sensor and sediment sampling mechanism information.
05 Vertical thruster power knob.
06 Spot light on/off switch.
07 Create new video file icon.
08 Record video icon.
09 Save video file icon.
10 Screenshot icon.
11 ROV stop icon.
12 Joystick on/off icon.
13 Error display panel.
7.6. Main Limitations of Control System
7.6.1. Batteries On-Board ROV
In its current state, the control system requires two LiPo batteries to be positioned on-board the
ROV. If water ingress were to occur, such positioning would present a serious safety hazard, both
to the batteries and the surrounding components. It is suggested that any future developments of
the control system includes the replacement of these batteries with voltage regulators to step
down the voltage of the 22.2 V thruster power supply.
7.6.2. Leak Detection
There is currently no hardware in place which can automatically detect the ingress of water into
either hull. Potential solutions have been researched but it was not possible to develop any
designs. The most promising solution researched involves the use of two strips of copper tape

38
(Open ROV, 2013). The strips are placed sufficiently close to one another such that droplets of
water are able to bridge the gap, causing an electrical connection.
7.6.3. Vision
The camera on-board the ROV only provides vision in the forwards direction. Additional cameras
would be desirable to provide vision in multiple directions, as well as to confirm correct
deployment of the microsensor deployment and sediment sampling mechanisms. However, it is
unlikely that the current connection between the ROV and user PC would be able to accommodate
multiple image streams. Modifying the control program to allow the user to select between
different cameras is one possible solution.
8. Buoy
Early on in the project it was decided that the ROV would be tethered to a floating base station
that would allow the range of the ROV to be increased. Initially it was envisaged that this would
be in the form of a trailer, towed by the hovercraft. It was decided that this may encompass too
much work for the hovercraft team in the first year of their project. A buoy was chosen to provide
the required base station, giving a stable buoyant platform from which to offer a link between the
ROV and the laptop controller on a boat or the shore.
The buoy was intended to increase the range of the ROV, to the design criteria of 50-200m. This
was achieved by using a Wi-Fi router to create a local wireless network connection from the laptop
to the buoy. An Ethernet cable was then used to connect the buoy to the ROV. The issue of
electrical loses over long lengths of cable was also reduced with this design, with a 25m power and
Ethernet tether being adopted, instead of much longer cables.

39
Due to the addition of the sensor deployment and sediment sampling mechanisms, it was decided
that the second hull on the ROV could no longer be used for housing the batteries that powered
the thrusters. Coupled with the need to purchase new batteries at the beginning of the year, it
was decided that the buoy would also act as the location for the batteries for the thrusters,
therefore freeing up a hull for additional components.
8.1. Final Design
8.1.1. Electrical Components
The buoy had to accommodate four thruster batteries for required mission time. A Wi-Fi router
was needed to transfer data between the controlling laptop and the myRIO on the ROV. An Edimax
BR-6428NS was selected as it allowed connection speeds up to 300 Mbps which was adequate for
the quantity of data transfer. The Wi-Fi router is powered by a separate USB battery, eliminating
the requirement for a step-down voltage circuit in the buoy and creating a secondary system so
that if the thruster batteries fail, there is still a link with the ROV. The USB battery supplied the
required current of 1 Amp and 5 Volts and had twice the capacity required for the mission time.
8.1.2. Dry box
A dry box was used to accommodate all the electronic components for the buoy. A LoMo Medium
dry box was used which had an O-ring design and two lockable catches to ensure waterproofness.
The electrical components described above were accommodated within the dry box. To stop the
components moving around, which could lead to cable connectors being dislodged, a 3D printed
interior was designed and manufactured (Figure 24). The interior was manufactured from twenty
parts due to the size of the printing bed. The parts were designed with lap and peg in hole joints
which gave some structural rigidity. Glue was also used to secure the parts together. The batteries

40
were held in pace with small battery clips which can be bent for the removal of the batteries. The
Wi-Fi router is fixed to the inside of the dry box lid, with the antenna drilled through and sealed.
Figure 24: Drybox interior
8.1.3. Chassis
The final design for the buoy can be seen in Figure 25. The chassis is made from the
aforementioned machine building systems speed frame and the dry box is secured to the chassis
by two bungee cords. The chassis fits together by using T-slots and automatic fastening sets with
M6 bolts. The chassis also adds legs to the buoy which provides a flat base for the buoy to sit on
dry land. The legs were required as the Bulgin waterproof connectors protrude from the base of
the drybox, thus it would be unable to sit flat on dry land.

41
Figure 25: Final Buoy design
8.1.4. Soil pipe
As can be seen in Appendix H: Buoy Design many
designs were considered to supply the buoyancy
for the buoy. Cylinders had been considered but
after the issues with the end caps on the ROV hulls
it was decided to use an off the shelf end cap
sealing system. To create an airtight space four
ninety degree angle connectors were used to
connect four lengths of soil pipe together to from a rectangular shape. The angled connectors have
built in lip seals and are sealed with a push fit. Silicone greases was used to lubricate the lip seals
to protect them and ensure waterproofness. Four off the shelf brackets (Figure 26) were used to
connect the soil pipe arrangement to the chassis. The brackets simply fit around the soil pipe and
were then attached to the chassis by two M6 bolts for each bracket.
Buoyancy hand calculations were used to determine if the quantity of soil pipe used would be
sufficient (Appendix H: Buoy Design, Table 14: Buoyancy hand calculations.). The soil pipe displaces
0.024m3 of water. The volume that needed to be displaced was 0.014m3, this is approximately
Figure 26: Bracket connectors.

42
twice the required displacement. Figure 27 shows that the waterline on the buoy was halfway up
the soil pipe; therefore proving the calculations were correct.
Figure 27: Buoy waterline.
8.2. Centre of buoyancy and gravity
To ensure the stability of the buoy the centre of buoyancy and centre of mass needed to have
similar X and Y values so they are in line with each other in the vertical axis. The centre of mass
was determined by setting all the mass properties within the CAD model and using the centre of
mass function. The water level was determined by making all the parts solid with water properties.
Then a horizontal plane was moved up and down until the mass of water below the plane equalled
the total mass of the buoy. Figure 27 shows the position of the water level line. The centre of
buoyancy is then the centre of mass for water model below the water level line.
Figure 28: Centre of Mass (left), Centre of Buoyancy (Right).

43
Figure 28 shows the position of the centre of mass (left) and centre of buoyancy (right). The centre
of mass and buoyancy co-ordinates are (-145,-238,-27) and (-143,-238,-42) respectively. It can be
seen that the difference in X is 2mm and Y is the same. This difference is minimal; therefore it will
not affect the stability of the buoy. The distribution of mass within the drybox was carefully
thought out to keep it symmetrical; therefore keeping it stable in the water. The centre of mass is
15mm above the centre of buoyancy in the Z direction, this difference is also small. If the buoy
sinks further into the water on one side, due to currents or waves, the centre of buoyancy will
move thus creating a restoring moment which will restore the buoy to its original position.
8.3. Bulgin Waterproof connectors
Two cables are required to transmit power and control signals from the buoy to the ROV. The
power and Ethernet cables need to enter the dry box to connect to the router and batteries. To
provide waterproof connections Bulgin IP68 connectors were used. A hole saw was used to cut
two holes in the base of the dry box for the connectors. The connectors screw together each side
of the dry box to provide a waterproof female port on both sides. The external cables, between
the buoy and ROV, have waterproof ends which attach to the connector on the dry box. The
arrangement adopted enables the cables to be detached from the buoy and the ROV for
transportation. When the buoy
is placed on a flat surface the
legs attached to the chassis
ensure that the protruding
connectors are not bent or damaged. The connectors protrude by 10cm bellow the dry box when
the cables are connected (Figure 29).
Figure 29: Bulgin connector position.

44
8.4. Tether Management System (TMS)
With the ROV now being attached to a floating buoy instead of
being operated from a boat it was decided that a Tether
Management System (TMS) would be required to help prevent the
Ethernet and power cables becoming tangled. The purpose of a
TMS is to lengthen and shorten the tether in order to minimise the
effect of cable drag during use. Work detailed in the ROV Manual (Christ & Wernli, 2011) and by
Abel (1994) was studied and used as a basis for investigating tether design and management.
Significant research was undertaken into commercially available
systems, to gain an understanding of what designs have been
developed. Many simple designs are based upon a manual payout
from a boat, which can be seen in Figure 30 (rovinnovations, n.d.).
A typical design for an automatic system can be seen in Figure 31
(malmorstad, n.d.). There are two main design types of TMS, top
hat and side entry cages. A side entry design is simply a box that the ROV is parked inside of while
it is raised and lowered in the water, Figure 32 (seaeye, n.d.). A Tophat sits on top of the ROV and
does not enclose the ROV as a side entry cage does.
The final adopted solution to the TMS was to use a neutrally
buoyant tether. With a neutrally buoyant tether, the force
required by the ROV to pull the cable underwater or bring it to the
surface is minimal. To achieve a neutrally buoyant tether a floating
rope was platted together with the power and Ethernet cables.
Figure 30: Manual cable reel pay-
out
Figure 31: Commercially available
TMS system
Figure 32: Side entry cage.

45
However, the floating rope did not provide enough buoyancy to counteract the mass of the cables.
Small floats made of foam were available from the previous year’s project. The volume of the
floats was determined by submerging the float in a measuring cylinder filled with water and
recording the increase in volume. It was then calculated that a float was need every 6.2m to
provide the required buoyancy. Appendix I: Tether Management System Design shows the
calculations used to determine how many floats were required and the size of the intervals
between them.
During the third test the neutrally buoyant cable was tested with the buoy. The cable worked as
expected. The ROV was able to pull the tether
underwater with ease and no change in the ROVs
pitch or roll was witnessed. The excess cable floated
near the surface; therefore there was no force on
the ROV from the tether. When the ROV surfaced
the tether followed behind and was not having any
effect on direction or speed. Figure 33 shows the
cable during the third test. It can be seen that the
cable sinks between the floats. To increase the
effectiveness and reduce the quantity of
submerged cable smaller floats at more regular intervals should be used.
Figure 33: Neutrally buoyant cable.

46
To conclude, the tether management system deployed with the ROV is a neutrally buoyant tether
which does not have any effect on speed and direction of the ROV therefore achieving the aim of
the TMS.
9. Full System Validation
9.1. Dry Land Test
9.1.1. Thruster Response
The thrusters were found to respond correctly to user commands inputted using both the
keyboard and Xbox control pad.
9.1.2. Wireless Communication
The range and speed of the wireless communication was tested outdoors. Without the USB aerial
connected it was found that the wireless connection dropped out when the router was moved
more than 20 m from the user PC. The ROV’s response time suffered an approximate 0.5 s delay
when commands were sent using the wireless connection.
9.2. Pool Test
It was necessary to perform a third pool test in order to validate the aspects of the design that
could not be validated during the dry land test. The pool test was performed in a 3.8 m diving pool
located at the Sobell Leisure Centre, Aberdare. The objectives of the test were as follows:
 Validation of the ROV’s waterproofness.
 Correction of any alterations in the ROV’s pitch and roll resulting from chassis
modifications.
 Assessment of the ROV’s buoyancy.
 Validation of the buoy’s buoyancy and waterproofness.

47
 Validation of the tether management system.
 Calibration of the ROV’s depth sensor.
 Assessment of the ROV’s manoeuvrability in three dimensions.
 Assessment of the underwater visibility provided by the spot light and camera.
 Identification of any unforeseen issues.
Originally it was also planned to validate the underwater capability of the sediment sampling and
micro-sensor deployment mechanisms during this pool test. However, due to manufacturing
delays it was not possible to assemble either mechanism before the test.
9.2.1. ROV Waterproofness
The waterproofness of the ROV’s chassis was validated a week prior to the pool test to allow time
for any necessary modifications and to reduce the risk of damage to electronic components. Three
possible points where water ingress could have occurred were identified; the replacement cable
glands, replacement end cap O-rings and Bulgin® connectors. One hull fitted with all three of these
features was filled with weights then lowered to the bottom of the 3.8 m pool. The hull was left
for 45 minutes then removed from the pool. It was found that no water ingress had occurred
therefore it was agreed that a full system test could commence safely.
9.2.2. ROV Pitch and Roll
The ROV exhibited no significant pitch or roll when in the water, as can be seen in Figure 34.

48
Figure 34: ROV exhibiting neither pitch nor roll.
9.2.3. ROV Buoyancy
The ROV was found to be negatively buoyant. It was found that operating the vertical thruster at
50% power enabled the ROV to maintain a constant position in the vertical axis. It was anticipated
that this value of power would be reduced with the addition of the sediment sampling mechanism
due to its extra buoyancy.
9.2.4. Buoy Buoyancy and Waterproofness
The buoy was found to float easily and sat level on the surface of the water as expected. This is
shown in Figure 35.
In order to simulate waves the buoy was
pushed down on one side until the soil
pipe was fully submerged and then
released. Upon release the buoy
returned quickly to its original position,
Figure 35: Buoy floating level on the water’s surface.

49
thus proving that the change in position of the centre of buoyancy gave the required restoring
moment.
The dry box and soil pipe were disassembled after the pool test and examined for any water
ingress. None was found, proving that all seals on the buoy were watertight.
9.2.5. Tether Management System (TMS)
It was found that the floats attached to the
tether provided sufficient buoyancy to
prevent the tether from sinking. Figure 36
shows how the floats remained on the surface
of the water with the cables suspended
between each float.
It was also found that each float provided minimal resistance to the ROV when descending or
moving in the horizontal plane.
Tangling of the tether was found to be a problem with all 25 m of tether released. Appendix I:
Tether Management System Design details possible solutions to this issue with the use of a motor
driven reel.
9.2.6. Depth Sensor Calibration
Voltage readings were acquired from the depth sensor every 0.5 m, starting at a depth of 0.5 m
up to a depth of 3.5 m. The relationship between depth (𝑧, m) and output voltage (𝑉𝑜, V) was found
to be roughly linear between this range and is described by the following equation:
𝑉𝑜 = 0.032𝑧 + 2.06
Figure 36: TMS in action.

50
It was acknowledged that this relationship may not be true for the entire operating depth of the
ROV. It was planned to use a dead weight tester located in the mechanical workshop to calibrate
the sensor up to a depth of 20 m, however this was not possible due to time constraints.
9.2.7. ROV Manoeuvrability
The ROV was able to move in all directions and responded with minimal delay to user commands.
It was decided not to measure the ROV’s velocity in each direction as it was likely that the results
obtained would be affected by the addition of the sediment sampling and micro-sensor
deployment mechanisms.
9.2.8. Unforeseen Issues
It was not possible to assess the underwater visibility of the camera with the spot light due to a
fault in the control program’s code. The fault was rectified at a later date, however there was not
another opportunity to assess the camera’s visibility with the spot light.
The wireless connection between the user PC and Wi-Fi router was lost on numerous occasions
during the test. Reconnection was possible, however this was a time consuming process during
which the ROV could not be controlled. The connection appeared to be more stable when the
Edimax USB aerial was removed but disconnections still occurred. Further investigation after the
test identified an IP address clash on the router. This was due to the fact that the IP address for
the Ethernet adapter had changed following a software update on the myRIO. Once the issue was
rectified, the Wi-Fi connection was found to operate without any issues.

51
10. Future Recommendations
Based upon the system limitations outlined in previous sections of this report, Table # details
recommended areas for future development.
Table 6: Recommended future developments.
Category Development
Buoy Hardware &
Chassis
Motor driven Tether Management System. See Appendix I: Tether
Management System Design for further details.
Control Systems &
Communication
Establish communication between myRIO and stepper motor
controller.
Implementation of a leak detection system.
Replacement of batteries on-board ROV with voltage regulators.
Sensors & Sampling
System Hardware
Replacement of microsensor deployment mechanism Nitrile O-rings
with Viton O-rings.
Validation of microsensor deployment mechanism sealing during
motion.
ROV Hardware &
Chassis
Ease of assembly and disassembly.

52
11. Final Summary
Table 7 details the deliverables agreed upon at the beginning of the project and their status at the
end of the 2014/15 academic year.
Table 7: Status of project deliverables.
Deliverable Status Comments
Resolution of outstanding ROV issues. Achieved
Development of a microsensor
deployment system.
Partly
Achieved
Problems encountered implementing
control code. Full system validation not
performed as a result. Further details
provided in Section 5 and Appendix F:
Microsensor Deployment Mechanism
Design.
Development of a sediment sampling
system.
Partly
Achieved
Waterproofing of system not complete.
Full system validation not performed as a
result.
Modification of ROV chassis to allow
for attachment of microsensor and
sediment mechanisms.
Achieved
Development of buoy for the purpose
of wireless communication and ROV
power supply.
Achieved
Development of Tether Management
System
Partly
Achieved
Floating cable system implemented.
Research performed into passive and
motor driven cable reel mechanisms.
Development of user friendly control
program.
Achieved

53
12. Table of References
Abel, B. A., 1994. Underwater Vehicle tether management systems. Brest, IEEE, pp. 495-500.
Bentley, C. et al., 2014. En410t UAV Project - Autonomous Submarine, Cardiff: s.n.
British Standards Institute, 2008. BS ISO 3601-2: Housing Dimensions for General Applications,
s.l.: British Standards Institute.
Christ, R. D. & Wernli, R. L., 2011. The ROV Manual: A User Guide for Observation Class Remotely
Operated Vehicles. s.l.:Butterworth-Heinemann.
Environmental Sampling Supply, 2015. Products. [Online]
Available at: http://www.essvial.com/Products.aspx?ID=16
fixya, n.d. [Online]
Available at: http://www.fixya.com/support/t13021190-how_can
[Accessed 05 05 2015].
Hobby King Ltd., 2014. Turnigy 2200 mAh 3S 20C Lipo Pack. [Online]
Available at:
http://www.hobbyking.co.uk/hobbyking/store/__8932__Turnigy_2200mAh_3S_20C_Lipo_Pack.
html
[Accessed 4 November 2014].
Hobby King Ltd., 2014. Turnigy 5000mAh 6S 20C Lipo Pack. [Online]
Available at:
http://www.hobbyking.co.uk/hobbyking/store/__9176__Turnigy_5000mAh_6S_20C_Lipo_Pack.
htmh
Home Built ROVs, 2015. Mayfair 750 GPH Bilge Pump Thruster Testing. [Online]
Available at: www.homebuiltrovs.com/mayfair750test.html
homebuiltrovs, n.d. [Online]
Available at: http://www.homebuiltrovs.com/seafoxretrofit.html
[Accessed 05 05 2015].
hozelock, n.d. [Online]
Available at: http://www.hozelock.com/watering/hose-reels/auto-rewind/20m-autoreel-
2490.html
[Accessed 05 05 2015].
malmorstad, n.d. [Online]
Available at: http://www.malmorstad.com/products/tms
[Accessed 05 05 2015].
McLennan Servo Supplies, 2015. [Online]
Available at: http://www.alzanti.com/datasheets/european/stepper/35dbmseriesdla.pdf

54
National Instruments, 2013. User Guide and Specifications. [Online]
Available at: http://www.ni.com/pdf/manuals/376047a.pdf
Open ROV, 2013. Water/Leak Detector Circuit. [Online]
Available at: https://forum.openrov.com/t/water-leak-detector-circuit/251
[Accessed 30 March 2015].
Phidgets, 2015. OS - Linux. [Online]
Available at: www.phidgets.com/docs/OS_-_Linux
Phidgets, 2015. Phidgets Unipolar 4 Motor. [Online]
Available at: www.phidgets.com/products.php?product_id=1062_1
rovinnovations, n.d. cable-reels. [Online]
Available at: http://www.rovinnovations.com/cable-reels.html
[Accessed 05 05 2015].
SeaBotix Inc., 2007. Standard Thruster & 2 Wire Whip. [Online]
Available at: http://www.seabotix.com/products/pdf_files/BTD150_Data_Sheet.
seaeye, n.d. [Online]
Available at: http://www.seaeye.com/tms.html
[Accessed 05 05 2015].
stevenmcclements, n.d. [Online]
Available at: http://stevenmcclements.blogspot.co.uk/
[Accessed 05 05 2015].
Unisense, 2015. [Online]
Available at: www.unisense.com

55
Appendix A: Bill of Materials

56
Appendix B: ROV Chassis
The first design iteration consists of four straight legs as shown in Figure 37. This design was
disregarded, as there would be an insignificant improvement to the stability of the ROV.
Figure 37: From left to right, top to bottom; first, second, third and fourth chassis design iteration.
The second design iteration consists of four legs placed at an inclined angle. This design has a wider
base compared to the first design hence the improvement of overall ROV stability.
The third design iteration consists of only three legs instead of four as in any previous design
iterations. The decision of having three legs was made due to the possibility of having at least one
of the legs (in a four-leg design) not being in contact with the seabed in a worst case scenario (e.g.
on a highly uneven surface), resulting in the possibility of the ROV tipping over. As the sediment
and sensor deployment are integrated as part of the legs, the risk of having one of the legs not
1 2
34

57
being in contact with the seabed would mean the sediment and sensor deployment might not
function properly. Having only three legs can help eliminate such a risk.
The fourth chassis design iteration consisted of three legs arranged in a symmetrical manner. This
design has better overall weight distribution compared to the third design due to its symmetrical
arrangement. This design was also thought to have insignificant effect on the ROV
manoeuvrability, as there was no component in which the direction of each thruster is facing. The
final design was developed mainly based on the fourth design and involved using fabricated
reinforcement plates and machine building systems’ fastener sets. The original chassis frame was
also modified to widen the base and provide a more secure platform to attach the legs.

58
Appendix C: ROV Hulls
Numerical Validation: Hand Calculations
The following equations were used to calculate the stress acting on the 3mm thick hulls at 20m
depth of water.
Circumferential Stress:
σc = [(pi ri
2
- po ro
2
) / (ro
2
- ri
2
)] - [ri
2
ro
2
(po - pi) / (r2
(ro
2
- ri
2
))]
Axial Stress:
σa = (pi ri
2
- po ro
2
)/(ro
2
- ri
2
)
Radial Stress:
σr = [(pi ri
2
- po ro
2
) / (ro
2
- ri
2
)] + [ri
2
ro
2
(po - pi) / (r2
(ro
2
- ri
2
))]
pi = internal pressure in the tube (MPa) = 0.1 (atmospheric pressure)
po = external pressure in the tube (MPa) = 0.3 at 20m water depth
ri = internal radius of tube (mm) = 124
ro = external radius of tube (mm) = 130
r = radius to point in tube or cylinder wall (mm) (ri < r < ro)
Table 8: Stresses at various positional along the hull.
Radial Position (r) At 124mm At 130mm
Axial Stress -2.3178 -2.3178
Circumferential Stress -4.5357 -4.3357
Radial Stress -0.1 -0.3

59
Numerical Validation: FEA Modelling
Figure 38: Von Mises stress distribution.
The pressure hull was modelled by using Patran software. A simple hollow cylinder was created to
represent the pressure hull and uniform rectangular grid cells were generated automatically by
Patran. The displacement of each end of the tube was constrained 20mm from the edge which is
the actual overlapping distance between the end cap and the tube. The material (polycarbonate)
was assumed to have Young’s modulus of 2.3GPa and Poisson’s ratio of 0.37. The inner pressure
of the tube was assumed to be at atmospheric pressure, which is 1 bar whereas the outer pressure
of the tube was set to be 3 bar (at 20m water depth). The end result was plotted as Von Mises
stress distribution and a maximum stress value of 4.43MPa was obtained. The maximum safety
working stress of the material according to the manufacturer is 10MPa and under normal
circumstances the pressure hull would be working at approximately half of the maximum safety
working stress to give a safety factor of 2. The stress concentration is located nearby the region
where the end cap stops overlapping at both end of the pressure hull as shown in Figure 38.

60
Appendix D: ROV Buoyancy calculations
The ROV was designed to be slightly negative buoyant; therefore the mass of the ROV needs to
exceed the mass of water displaced. The total mass of the ROV with all cabling and systems
attached was 16.2Kg. The total volume displaced by the ROV was determined from the
Solidworks CAD model and was 0.015593m3. The mass of water displaced was calculated by
multiplying the volume by the density of water as seen below. The density of fresh water was
taken as 1000Kg/m3 and sea water was taken as 1035Kg/m3.
0.015593 × 1000 = 15.6𝑘𝑔 𝑜𝑓 𝑏𝑢𝑜𝑦𝑎𝑛𝑐𝑦 𝑖𝑛 𝑓𝑟𝑒𝑠ℎ 𝑤𝑎𝑡𝑒𝑟
0.015593 × 1035 = 16.1𝑘𝑔 𝑜𝑓 𝑏𝑢𝑜𝑦𝑎𝑛𝑐𝑦 𝑖𝑛 𝑠𝑒𝑎 𝑤𝑎𝑡𝑒𝑟
The difference between the mass of water displaced and the mass of the ROV determines the
amount of buoyancy.
15.6 − 16.2 = −0.6𝑘𝑔 𝑖𝑛 𝑓𝑟𝑒𝑠ℎ 𝑤𝑎𝑡𝑒𝑟
16.1 − 16.2 = −0.1𝑘𝑔 𝑖𝑛 𝑠𝑒𝑎 𝑤𝑎𝑡𝑒𝑟
This corresponds to a downward force of:
0.6 × 9.81 = 5.886𝑁 𝑖𝑛 𝑓𝑟𝑒𝑠ℎ 𝑤𝑎𝑡𝑒𝑟
0.1 × 9.81 = 0.981𝑁 𝑖𝑛 𝑠𝑒𝑎 𝑤𝑎𝑡𝑒𝑟
In fresh water there is a force of 5.89N downwards and in sea water the force is 0.98N; therefore
the vertical thruster power output will need calibrating depending on the type of water it is
being deployed in.

61
Appendix E: Enlarged Hull Design
Figure 39: ROV with new extended hulls
Table 9: Weight and dimensions of data logger (Unisense.com).
Dimensions (W × D × H) /mm 225 × 125 × 62
Mass (Approx.) /kg 2

62
Figure 40: Drawing for new hull cylinders
Figure 41: Drawing of new end caps

63
Appendix F: Microsensor Deployment Mechanism Design
Photos of Unisense Microsensors
Figure 42: Unisense O2 MicroOptode (Unisense.com)
Figure 43: Tip of MicroOptode with glass fibre partially extended (Unisense.com)
Figure 44: Normal microsensor deployment method (Unisense.com)
Figure 45: Unisense Microelectrode (Unisense.com)
Figure 46: Unisense reference electrode (Unisense.com)
Initial Design Concepts
Linear Actuator Concept
The figures in the previous section show that the microsensors use either glass fibres or glass
needles to take measurements and are therefore extremely delicate. They are also very expensive.

64
This meant that protecting them from damage during the mission was an essential design
consideration. The safest place for the sensors appeared to be inside the ROV chassis, however
there was not enough vertical space to mount them. It was decided that legs would be added and
the sensors would be mounted on sliding mechanisms on the inside of the legs.
The next stage was to decide on a mechanism to provide the
linear motion needed to lower the sensors into the sediment
and then raise them back up. Initially linear actuators were
considered for the task. They were available in a variety of
specifications, including waterproof versions, and could
provide a compact mechanism which would be reasonably
simple to implement. The actuator would be mounted onto
the chassis frame next to the leg with a connecting arm
attached to the sliding mechanism. When the operator
wished to deploy the sensor a command would be sent from
the myRio to the actuator’s controller, called a ‘dumb’
controller as it could only output speed and position commands. A concept of this system is shown
in Figure 47.
It was quickly found however that waterproof actuators were too expensive for the project. A
quote from Vipa gave a cost of £349.98 per actuator. The quote is shown in Table 10. The idea of
using linear actuators was abandoned in favour of a cheaper alternative.
Figure 47: Concept for a deployment
system with linear actuators.

65
Table 10: Quote from Vipa for waterproof actuators.
Rack and Pinion concept
As discussed in the previous section a cheap alternative to linear actuators was needed. The main
reason for the high cost was the need to waterproof electronic components to an IP69 rating which
would allow them to operate at depths of 20 metres. The solution seemed to be to buy a standard
electric motor and then waterproof it in house. This presented two challenges; how to waterproof
the motor and how to translate the rotary motion of the electric motor into linear motion.
Waterproofing Electric Motors
Bilge Pump
In the first design, the modification of a bilge pump was considered for the drive of the sensor
holder. Bilge pumps are designed to run continuously underwater so removing the casing and

66
exposing the shaft would have provided a reliable drive for the gear rack. The bilge pump that was
considered was the Mayfair 750gph bilge pump, tested to show
a capability of running up to 30 meters depth.
There were, however, some design complications in the use of a
bilge pump. First, at depth the high pressures applied to the lip
seals on the shaft would have increased the frictional torque on the shaft, thus the current drive
required increased. This higher force and current requirement would make the calibration of
motion difficult.
This, with the additional factor that dry running of the pump would cause damage to the motor
would mean the delicate motion required for the sensors would not be applicable.
Potting and Capsuling
Potting is a process of which the complete electronic assembly, or the motor coils in this scenario,
are filled with a solid or gelatinous compound for exclusion from moisture. The added benefits
from the system are a simplicity in the design, as well as additional protection from impact, shock,
and vibration. Notable materials include wax, epoxy resin, and plastics.
Capsuling involves a similar process in which the motor electronics are enclosed within a
watertight box with a push rod through a port sealed with the use of O-rings. For additional
security the servo electronics would have been filled with a non-conductive oil.
However, both methods are crude and have a chance of damaging or breaking the motor. In the
case of encapsulating the motor, the oil may even increase the current draw from the motor.
Figure 48: Mayfair 750 Bilge Pump.

67
Magnetic Coupling
As the previous waterproofing designs were found to be crude and damaging to the application of
the motor, complete separation of the motor and drive was considered. In this case, magnetic
coupling.
Magnetic coupling is used to transmit the torque between two unconnected components through
the use of magnetic force. In the interest of the movement of the sensor, magnetic coupling would
be used for the complete separation of the two coupled parts. Thus meaning the motor may be
sealed off from the water whilst still providing the required driving force. Additionally, a lack of
contact between the parts would give an additional benefit in reduced friction, wear, noise, and
removes the requirement of lubrication.
In the design, as shown in Figure 49 a set of magnets may be attached to the motor shaft within a
completely sealed container. The wiring
may enter this housing through the use of
potting as they will not be required to
move. A second set of magnets may be
mounted within the ring with an internal diameter larger than the cylindrical waterproof housing.
Though the design would have provided a long lifetime of use and a fully waterproofed system,
the magnets would interfere with the sensor equipment and amplification attached alongside it.
The Unisense pH meter has an input range of ±4500pA with an input impedance of 1013 Ohm, and
it is recommended by Unisense specification to avoid forms of electronic or magnetic interference.
Due to this, magnetic coupling could not be used.
Figure 49: Magnetic coupling concept.

68
Motion Translation Methods
There were several possible methods of mechanically translating rotary to linear motion which
were considered. Initially variations of the Crank – Slider and the ‘Scotch Yoke’ mechanisms were
investigated. The advantage of these systems was that the amount of travel and the speed of
motion was built in mechanically by the size of the main gear and the lengths of the slider
components. This meant that the motor did not need a controller with position control and could
be controlled by simple on/off commands from the myRio. However both mechanisms would have
been unnecessarily complex to manufacture and would have needed a comparatively long length
of chassis frame to mount them. Due to the thruster layout the amount
of space for deployment mechanisms was limited so a more compact
system was needed.
It was decided that a rack and pinion system was the best option as it was
the most compact and also had the fewest moving parts making it the
simplest to manufacture. Both the rack and the pinion would be
manufactured in house using 3D printing to save the cost of buying
custom made components from an external supplier. A concept for this
system is shown in Figure 50. Unlike the other mechanisms there was no
mechanical limit to the amount of travel so a controller would be needed
to provide position control to ensure that the rack did not move too far
and escape its slide. This was preferable as a compact system that could be easily mounted to the
chassis was more important. However it was eventually decided that even this system was
unnecessarily complex as the pinion, the rack and the rack’s slider would have to be designed and
Figure 50: Concept for a
rack and pinion
deployment system.

69
manufactured and other methods for achieving linear motion would be simpler and more
effective.
Final System Design
It was decided that the best way to achieve linear motion was to
use stepper motors. These are electric motors which rotate what
is effectively a threaded nut. This rotation moves a threaded rod,
known as a lead screw, linearly up and down. Once this motor had
been chosen there were two main tasks. The first was design the
control system of the motor, including defining the positions to
which the motor would have to travel to deploy and retract the
sensor, and to integrate this system with the myRio controller
used to control the ROV. The second was to design and construct
the waterproof casing around the stepper motor and the mechanism which allowed the motor to
deploy the sensor.
Stepper Motor and Controller
In the operation of a stepper motor, the motor drive differs from general DC motors in that it is
driven by current pulses, which generates discrete rotations of the motor shaft.
The stepper motor has input contacts of which allow the current from the supply into the coil
windings. As mentioned, pulsed waveforms in the correct pattern is required to create the
electromagnetic fields needed to drive the motor. Stepper motors may also move an exact amount
of degrees (or steps) giving full control over the motor, which allows motion to an exact position
Figure 51: Stepper motor with
leadscrew (Mclennan Servo
Supplies).

70
and to hold that position. Due to this complexity of the drive, a stepper motor controller was
required to energize the phases in a timed sequence to make the motor turn.
In the decision of the motor controller, a Phidget unipolar stepper motor controller was chosen
for features including the ability to control 4 differing stepper motors through a single chip. In the
case of the project, three of these ports are used for the control of the three Unisense sensors
required. The fourth port is currently unused and thus may be used for implementation into future
developments of the system.
The stepper motor controller has a requirement of a supply of a maximum of 12V with a current
consumption of up to 100mA. This may be easily taken from the batteries on-board the ROV hulls
or elsewhere.
Stepper Motor Connections
To produce the minimum amount of radiated noise, the motor leads are of a twisted construction.
The cable has a requirement to be
screened, with the screen
connected to an earth at the drive
end and to the motor body at the
motor end. The motor lead
configuration is shown in Figure
52.
Figure 52: Six lead motor of unipolar drive.

71
At each node of the stepper motor controller, labelled ports of a range of + A - D + may be found,
which corresponds to specific wiring from the stepper motor. Table 11 shows a simplistic wiring
colour guide for the stepper motor used.
Table 11: Stepper motor controller wiring guide.
Labelled Port + A B C D +
Designated
colour wiring
Red Yellow Black Orange Brown Red
The two red wires corresponding to the centre tap (+) are found grouped alongside the two wires
corresponding to them as three wires will exit from the top and bottom portion of the stepper
motor. Figure 53 below shows the Phidget stepper motor controller with the labelled ports.
Figure 53: Phidget’s 4 Stepper motor controller.
Control Program and myRIO Implementation
The provided libraries from Phidgets are not compatible with LabVIEW on a 64 bit Linux based
operating system. As the myRIO has the capability to program a processor running a real time OS
and a customizable field-programmable gate array (FPGA), the myRIO processor may be
programmed in C/C++ using the default shipping personality. However, it is only possible to
customize the FPGA through the use of LabVIEW. So, the operation of the stepper motors is driven
through the use of C/C++ program code implemented through LabVIEW.

72
In the development of the C++ code for the system, the required libraries were available through
download on the Phidgets website. The code was developed on an external Linux based operating
system using Eclipse CDT (C/C++ Development Tooling) which provides fully functional C and C++
integrated development Environment (IDE) based on the Eclipse platform. The fully implemented
code may be found within the attached CD.
Further Development of the Control Program
As the C++ program developed is not yet fully compatible with the myRIO, further developments
will be required for full integration into the system design. Steps necessary for development of the
code are discussed.
With the developed code provided and with the use of Eclipse, a shared library may be formed,
intended to be shared by multiple executable files. Program modules may be loaded from these
individual shared libraries into memory at run time. Eclipse gives the capabilities of developing
these shared libraries. When directly connected to the myRIO, the shared library form may be
imported into the local directories of the myRIO at ‘/usr/local/lib/’.
To implement the code into the myRIO, the LabVIEW VI ‘Call Library Function Node’ may be used
to directly call the Linux shared library function. This creates an interface to call the existing
libraries written for use in LabVIEW.

73
Waterproofing
Figure 54 shows the final design for the system. It consists of a
waterproof hull containing the motor, a plunger inside a tube and
a tube to protect the sensor. The leadscrew was attached to the
plunger by means of a threaded hole in the plunger. This was
reinforced with glue. The sensor holder was glued to the plunger
so that when the leadscrew moved the plunger, it moved the
sensor holder in turn.
The design of the waterproof hull was based in the design for the
main hulls. The tube used was 5mm thick polycarbonate. This was
chosen to ensure that the hull could withstand the pressure of
depths of 20 metres. The hull used end caps which were sealed
with O-rings conforming to the BS ISO 3601-2:2008. The lower end cap needed to be drilled to
allow the leadscrew down to the plunger. Therefore further waterproofing was needed. At first lip
seals were considered but these were found to be more suited to sealing rotating shafts and may
not have been as effective at sealing the plunger travelling linearly. Instead grooves were
machined into the plunger to house O-rings, in accordance with BS ISO 2601-2-2008, which then
formed a seal against the surrounding tube. The hole in the lower endcap was 15mm in diameter.
By chance this was also the maximum diameter of the microsensor. The tube therefore had to
have a diameter greater than 15mm. To allow for space for the sensor holder and plunger 3mm
thick polycarbonate tube with a 26mm internal diameter was chosen. 3mm wall thickness tube
Figure 54: Final system design with
brackets.

74
was chosen as it was the same thickness of polycarbonate used for the main hulls and this had
been shown by FEA to be sufficient to withstand the pressure at 20m.
O-Ring Calculations
As stated in the previous section O-rings were used to seal the hull and the plunger. The previous
project had sized the O-ring housing grooves incorrectly and this had led to the hulls leaking. It
was important that the correct dimensions for the grooves were found using the equations from
Annex B of BS ISO 3601-2:2008 as shown below.
The first step was to determine the bore, the inside diameter of the tube, denoted as 𝑑4 and the
piston diameter, the diameter of the end cap or plunger, denoted as, 𝑑9. The next step was to
identify the type of application. The O-rings for the end caps were identified as being used in a
hydraulic static application and their compression ranges were found from Figure 55. The O-rings
sealing the plunger were used in a hydraulic dynamic application and their compression ranges
can be found in Figure 56.
Figure 55: Compression ranges of O-rings for hydraulic static applications (BS ISO 3601-2-2008).

75
Figure 56: Compression ranges of O-rings for hydraulic dynamic applications (BS ISO 3601-2-2008).
Once the compression range had been found the depth of the housing, 𝑡 𝑥 could be found.
𝑡 𝑥 = 𝑑2 − [(𝐶 𝑛𝑜𝑚 × 𝑑2)/100]
Where 𝑑2 = the O-ring cross section and 𝐶 𝑛𝑜𝑚 = the nominal compression of the O-ring expressed
as a percentage.
The housing diameter, 𝑑3 could then be found by subtracting double the housing depth from the
bore of the tube.
𝑑3 = 𝑑4 − 2(𝑡 𝑥)
The depth of the groove was found from;
𝑔𝑟𝑜𝑜𝑣𝑒 𝑑𝑒𝑝𝑡ℎ =
𝑑9 − 𝑑3
2
The next step was to find the maximum inside diameter of the O-ring, 𝑑1,𝑚𝑎𝑥. BS ISO 3601-2-2008
recommended stretching the O-ring by 2% so 𝑑1,𝑚𝑎𝑥 was found from;

76
𝑑1,𝑚𝑎𝑥 = 0.98 × 𝑑3
Calculations for End-Cap O-rings
For the end cap O-rings the bore of the tube, 𝑑4, was 60mm and the piston diameter, 𝑑9, was
59mm. Figure 55 showed that for hydraulic static applications the compression range of an O-ring
with a 2.5mm cross section was between 13% and 30% so the nominal compression had to be
found.
𝐶 𝑛𝑜𝑚 = (𝐶 𝑚𝑎𝑥 + 𝐶 𝑚𝑖𝑛)/2
𝐶 𝑛𝑜𝑚 =
30 + 13
2
= 21.5%
The housing depth was then calculated;
𝑡 𝑥 = 2.5 − [21.5 × 2.5)/100] = 1.875𝑚𝑚
This gave a housing diameter of;
𝑑3 = 60 − 2(1.875) = 56.25𝑚𝑚
The depth of the grooves was;
59 − 56.25
2
= 1.375𝑚𝑚
Which led to a maximum O-ring inside diameter of;
𝑑1,𝑚𝑎𝑥 = 0.98 × 56.25 = 55.125𝑚𝑚
Therefore the O-rings chosen to seal the end caps had a cross section of 2.5mm, an inside diameter
of 55mm and were housed in grooves 1.375mm deep.

77
Calculation of Plunger O-rings
The bore of the tube was 26mm and the diameter of the plunger was 25mm. Figure 56 showed
that for hydraulic dynamic applications the compression range of an O-ring with a 2mm cross
section was between 13% and 26%. This gave a nominal compression of 19.5%. However it was
decided to use a larger compression to ensure that there was a good seal between the O-ring and
the tube so a compression of 25% was used.
𝑡 𝑥 = 2.0 − [25 × 2.0)/100] = 1.5𝑚𝑚
𝑑3 = 26 − 2(1.5) = 23.00𝑚𝑚
25 − 23
2
= 1𝑚𝑚
𝑑1,𝑚𝑎𝑥 = 0.98 × 23 = 22.5𝑚𝑚
Therefore the O-rings chosen to seal the plunger had a 2mm cross section, a 22.5mm inside
diameter and were housed in a 1mm deep groove.
Buoyancy Calculations
One of the objectives of the project was to get the ROV to be slightly negatively buoyant. This
meant that the weight and buoyancy of each component had to be found. As the models built in
Solidworks had been assigned material properties they could be used to get an estimate for the
mass of the component. The mass of the whole sensor deployment system including the brackets
was, according to Solidworks, 0.56kg. As the plunger moved up and down the amount of water
displaced changed. It was decided to calculate the buoyancy of the system when the plunger was
fully retracted and displacing the least water as this was where the plunger would be for most of
the mission. This meant that the plunger was approximately 10mm below the lower end cap.

78
Volume Displaced
There were two main volumes to calculate. The first was the motor hull. The second was the
volume displaced by the second tube from the lower end cap to the bottom of the plunger. Below
this was filled with water during the mission so no significant volume was displaced.
The volume displaced by the hull was;
𝜋(35 × 10−3
)2
× 135 × 10−3
= 5.195 × 10−4
𝑚3
The volume displaced by the second tube was;
𝜋(13 × 10−3
)2
× 60 × 10−3
= 3.186 × 10−5
𝑚3
The total volume displaced was;
5.195 × 10−4
𝑚3
+ 3.186 × 10−5
𝑚3
= 5.514 × 10−4
𝑚3
The mass of water displaced was;
1000 × 5.514 × 10−4
= 0.5514𝑘𝑔
The difference between the mass of the system and the mass of water displaced was;
0.56 − 0.5514 = 8.6 × 10−3
𝑘𝑔
This corresponds to a downward force of;
8.6 × 10−3
× 9.81 = 0.084𝑁
Solidworks estimated that the whole sensor deployment system had a mass of 0.56kg. As shown
above the mass of water displaced was 0.5514kg. This meant that the system was slightly
negatively buoyant with an underwater weight of 8.6 grams in fresh water giving a downward

79
force of 0.084N. As seawater is more buoyant than freshwater it is likely that the system will be
neutrally buoyant in the sea.
Sensor Holder
There had to be a mounting point for the sensor within the system. It was
decided that 3D printing a holder would be the best option. Figure 57 shows
the initial design of the sensor holder. It had an outer radius equal to that of
the plunger and in inner radius equal to that of the machined end of the
plunger so that they could be glued together as can be seen in Figure 58. The
sensor was held in a semi-circular bracket which it snapped into. However
this design relied on the 3D printer being able to
print the parts with the required level of accuracy.
The first trial part was too inaccurate. The sensor
could not fit in the bracket without some material being removed and
the radii did not match those on the plunger. It was also found that with
just one bracket the sensor had some freedom of movement. The
design was modified to include two brackets to hold the sensor in place
as shown in Figure 58.
Figure 57: Initial
sensor holder design.
Figure 58: Modified holder
design shown attached to
the plunger.

80
Brackets
It was chosen to mount the system on the outside of the
ROV’s leg because it had a protective tube around the
sensor and so did not need the protection gained from
being on the inside of the leg. 3D printed brackets were
designed to hold the system to the leg. To start with
brackets similar to the sensor holder were investigated
but this was considered unreliable as there was potential
for the whole system to slip out of the brackets. The
solution was to manufacture each bracket in two parts
which would be bolted together around the middle tube and would hold the system to leg by
means of t-nuts in the slots of the aluminium speed frame from which the legs were made. This is
shown in Figure 59.
The system was mounted with the lower end cap resting on top of
the leg preventing it from moving vertically downward. To prevent
vertical movement upwards another bracket was designed in a
rough ‘Z’ shape as shown in Figure 60. This was designed to be
bolted onto the top of the leg by means of t-nuts. Once in place it
would hold the motor hull down onto the top of the leg.
Figure 59: Brackets holding the system to the
leg.
Figure 60: Bracket to hold down
the deployment system.

81
Manufacturing delays
Problems with some of the 3D printing machines meant that the manufacture of the brackets and
the sensor holder was delayed by almost 5 weeks. Attempts were made to print them on a more
accurate printer than the one used to print the original sensor holder. However only the modified
sensor holder was successfully printed. The brackets had to be manufactured using the Selective
Laser Sintering (SLS) machine.

82
Appendix G: Sediment Sampling Mechanism Design
Sediment sampling is typically done either by deep sea diving or the use of more complex
machinery depending on the type and location of sediment. There are a suite of different sampling
tools, but for softer muds such as the one that is being studied for this mission, two tools in
particular were studied and researched. These include clamshell samplers or corers as shown on
the left and right of Figure 61 (stevenmcclements, n.d.) respectively.
As you can see these are fairly large devices and are typically operated with heavy machinery,
usually operated off the side of the boat. However, the principals are quite simple and our task
was to create a system that deliver the same method of collection but on a much smaller scale.
Figure 61: Typical Clamshell sampler and Corer sampler.

83
The clamshell sampler consists of two semi cylindrical scoops with a set of jaws that allow it to
close to collect sediment. This is a very effective tool for sampling the top few centimetres of soft
sediment but does disturb the sediment due to the operation of the jaws closing, this can lose
some important information when
analysing/testing. Our initial design idea was to
incorporate this mechanism into the
mechanical arm Figure 62, (homebuiltrovs,
n.d.). The customer required an opposable
arm as well as system to collect a small amount
of sediment and store the sample for further
testing and analysis. To do this, a mechanical arm with an attached clamshell scoop was
considered for the task of collecting sediment from the seabed. This would require a fixed arm
that would rotate using a standard 12V DC motor, at the end of the arm would be closing
mechanism that would operate using a solenoid once the arm was inserted into the surface.
However, after much deliberation it was concluded that the arm itself would be unnecessary for
the mission, the design would offer limited functionality and ultimately would take away time and
resources that could be used for more essential tasks.
Figure 62: Example of a mechanical arm.

84
Corers are simply core tubes with an
added weight attached to allow gravity to
push it into the sediment. Just like
clamshell sampler these are usually large
and operated using heavy machinery off
the side of a boat. The benefit of corers is
that they are much better at producing an undisturbed sample, which was desired by the
customer. After researching for small scale solutions for sampling, it was found the Environmental
Sampling Systems © offered a hand operated coring product shown in Figure 63 (Environmental
Sampling Supply, 2015), that would be able to collect 5-10g of sediment which was more than
adequate for the customer.
It was decided that LOCK N’ LOAD syringe should be implemented into the ROV design due to its
low cost and simple design, as described in Section 6. The section will describe the testing involved
to determine the appropriate actuation system.
Test 1 – Force test using sand
For the first test it was decided to use the LOCK N’ LOAD syringe and handle together to see its
effectiveness. Also by using the system how it was meant to be used it gave us a better of
understanding of how we could modify the system to better suit the actuation system.
For this test we placed a tank with a mixture of wet sand and water on a weighing scale and
measured the maximum weight recorded on the scale when a sample is taken. The weight of the
Figure 63: Lock N’ Load syringe and handle.

85
tank is then taken away to get the insertion weight and converted to Newtons to determine the
force as shown in Table 12.
Figure 64: Test 1 - Experimental setup.
Table 12: Test 1 - Results
Test No. Max Weight
/kg
Insertion Weight
/kg
Force /
N
Yield/g
1 24 11.1 109 6
2 28 15.1 148 13
3 25 12.1 119 11
4 27 14.1 138 9.5
5 23 10.1 100 6
6 25 12.1 119 10
7 25 12.1 119 9.5
8 26 13.1 129 9.5

86
Figure 65: Relationship between applied force and sediment yield.
As you can see from the Figure 65 the increase in force yields more sediment. The sediment that
is going to be tested for in this mission is in Cardiff bay and is much softer than sand, therefore it
is expected that the forces required in test 1 would be much lower when collecting the soft mud
in Cardiff bay.
Test 2 – Force test using mud from Cardiff Bay
For our second test we collected mud from Cardiff bay to closely examine the syringe’s
effectiveness on a softer sediment. It was determined early on that the sediment would be too
soft for the syringe to be push inserted and collect sediment, as the plunger would not push back
and thus yield little to no sediment. Therefore the methodology in which the syringes were used
was modified so that the syringe would actively suck up the sediment by restraining the plunger
while pushing the syringe body into the surface, as explained in section 6.
The test was conducted different in order to accommodate for the different methodology used.
As stated in section 6, the plunger was fixed while the body was free to move into the mud sample,
weights were added in 0.5kg increments until a suitable insertion was reached. From the test, it
0
20
40
60
80
100
120
140
160
0 2 4 6 8 10 12 14
AppliedForce/N
Sediment Yield /g

87
was established that the force required to insert and withdraw the syringe body was calculated to
be in the range of 20N-30N, the results can be seen in Table 13.
Table 13: Test 2 - Soft sediment results.
Run Weight/kg Force / N Yield/g
1 1.5 15 6
2 1.5 14.715 8
3 2 19.62 9
4 2.5 24.525 9
5 3 29.43 9
6 2 19.62 8
7 2.5 24.525 8.5
8 2 19.62 7
Other designs
The idea of using a vacuum to suck up sediment was also considered as a simple and effective way
to collect sediment. Using a Venturi principal for suction and a fixed dredge nozzle, the top layer
of sediment would be vacuumed and stored in a container as shown in Figure 66.
Figure 66: Dredge pump design.

88
After speaking to the customer however, it was established that it was important to keep the
sample undisturbed and preferably with its layers intact. Also the size and added weight of the
vacuum pump would have significantly affected the propulsion of the ROV.

89
Appendix H: Buoy Design
Chassis
Various design iterations were developed during the initial phases of the project. It was decided
to use the same machine building systems speed frame, as used on the ROV. The speed frame is
cheap and easy to make a variety of structures and allows future development of the buoy. Several
initial design concepts can be seen below in Figure 67, based on a typical offshore buoy used by
maritime services. However it was decided to base the buoy around a square construction as this
would be easier to manufacture and develop.
Figure 67: Buoy initial designs
Air Tight Container
The air tight container on the buoy needed to house four thruster batteries, a Wi-Fi router and a
Wi-Fi battery. The weight of these components was approximately 4Kg. Several different airtight
containers were discussed as to their suitability to house the electrical components. The initial
solution was to use cylinders to house the components, similar to the ROV hulls and they would
also provide the buoyancy (shown in blue in Figure 67). The hull idea was avoided due to the

90
difficulty of installing and removing the end caps, along with them needing to be securely held in
place once assembled.
It was finally chosen to purchase an off the shelf dry box and various companies were evaluated
against the cost of their product, suitability and sizing. It was decided that a LoMo medium dry box
would be suitable; it was made from ABS plastic. The dry box offered adequate space for all the
electrical components and an air tight seal with two lockable locks to ensure it did not open.
Buoyancy
Tyres and polycarbonate cylinders were discussed the supply the required amount of buoyancy
for the buoy. Using a tyre (Figure 68) and filling the internal gap with foam is a cheap solution,
however a tyre did not offer the structural rigidity and attaching locations for the chassis.
Figure 68: Tyre design
Cylinders (Figure 69), similar to the hulls on the ROV, were a better solution for adding buoyancy.
The cylinders used on the ROV where made from polycarbonate with machined end caps.
Problems with removing the end caps and O-rings breaking were present with the hulls.

91
Figure 69: Cylinder buoy design
To avoid leakage and machining time, soil pipe was decided to be used to supply the required
buoyancy. The soil pipe had an external diameter of 110mm and a wall thickness of 3mm. It is
manufactured form PVC-U which gives adequate strength and lightness. Four 90˚ angled
connectors were used to form a rectangular layout. The connectors use lip seals; therefore, the
soil pipe and connector give an airtight seal with a push fit. To connect the soil pipe structure to
the chassis, off the shelf brackets were used. The brackets were designed to be used with the soil
pipe; therefore this solution was cheap and adaptable. Table 14 shows the hand calculations used
to determine if the amount of soil pipe would provide the correct amount of buoyancy. It can be
seen that approximately twice the required displacement of water is generated from the soil pipe.

92
Table 14: Buoyancy hand calculations.
Component Weight/Kg Quantity Total/Kg
LoMo box 1.27 1 1.270
Router 0.50 1 0.500
Speedframe 2.50 1 2.500
Batteries for sub 0.77 4 3.060
Batteries for buoy 0.08 1 0.076
3-D Printed supports 0.50 1 0.500
PVC pipe 4.00 1 4.000
PVC fittings 2.00 1 2.000
Total 13.91
Buoyancy Required
Density of water 1000
Mass to equal 13.91
Volume required 0.0139 m^3
Volume of PVC pipe 0.0238 m^3

93
Appendix I: Tether Management System Design
A Tether Management System (TMS) was required to manage the power and Ethernet cable that
connected the ROV to the buoy. It was required as the cables are more dense than water therefore
they sink. The resultant force from the cable on the ROV would result in the ROV’s movements
being effected. The total mass of the power and Ethernet cable was 3.3Kg and the total mass of
water displaced was 1.75Kg thus resulting in a downwards force of 15.2N. The maximum thrust
available from the vertical thruster is 1.84Kg hence 18.1N. In the worst case scenario only half the
cable would be below the ROV thus the force would be 7.6N. This would only leave 10.5N of
upwards force from the thruster thus reducing the velocity of the ROV ascending. The downward
force of 7.6N would cause the ROV to descend when not wanted.
The purpose of the Tether Management System is to reduce the forces that the cables exert on
the ROV. These unwanted forces cause the ROV to deviate from its path and depth.
Hozelock hose reel
A Hozelock auto-rewind hose reel Figure 70
(hozelock, n.d.) was purchased to investigate its
feasibility as a tether management system.
The force need to unwind the hose was determined
by using a spring force balance and was found to be
50N. The ROV does not have enough thrust to supply
this force. To reduce the force, work was carried out to investigate the spring used in the hose
reel. The spring was a clock/power spring (Figure 71 (fixya, n.d.).
Figure 70: Hozelock® hose reel.

94
This type of spring is a manufactured by using a long strip
of steel and coiling it around the small central diameter.
The spring is housed within a large diameter housing. The
spring is attached to the small diameter and large
diameter housings at each end. When the hose is
unwound more coils are added as the real is rotated thus
storing more energy. The energy stored in the spring is proportional to the width multiplied by the
thickness squared. The energy stored within the spring needed to be reduced by a significant
amount. The force would need to be reduced to 10N as this would leave sufficient thrust from the
thrusters to move forwards.
The Hozelock spring would have needed to be de-rated by an amount that was not feasible with
the current spring and housing arrangement therefore this solution was neglected.
Neutrally Buoyant cable
Table 15 shows the calculations used to determine how many floats were required and the size of
the intervals between them.
Figure 71: Hozelock clock/power spring.

95
Table 15: TMS Float quantity and position calculations.
Future Work - Motor driven
The neutrally buoyant solution described above did not solve the problem of having twenty five
meters of cable floating in Cardiff bay. The tether could cause accidents such as getting caught in
a boats propeller. This was not addressed this year as other areas of development took priority
over developing this further. To resolve this issue a D.C motor could be used together with a reel
to store the cable on. A high torque low speed motor would be suitable for this application. For
example a D.C geared brushed motor, 24V, 2Nm, 7.2rpm and 3W at a price of £60. The motor
provides 2Nm of torque which is adequate to rotate a cable reel with the cable wound in. The
force needed to pull the cable in is minimal as the tether is neutrally buoyant. The D.C motor can
be powered by the on-board batteries which are used to power the thrusters.
Cable Length/m 25 Weight of float/Kg 0.04
Diameter of power cable/m 0.008 Volume/m^3 0.00035
Mass of power cable/Kg 2.642 Volume/L 0.35
Volume of power cable/m^3 0.001256637 amount of floats required 4.034268
Diameter of ethernet cable/m 0.005
Mass of ethernet cable/Kg 0.663 Float every/m 6.196912
Volume of ethernet cable/m^3 0.000490874
Diameter of rope/m 0.01
Mass of rope/Kg 1.818
Volume of rope /m^3 0.001963495
Total mass/Kg 5.123
Total Volume displaced/m^3 0.003711006
Mass of water displaced/Kg 3.711006322
Force downwards max/n -13.851658
force per meter of cable -0.55406632
volume needed to be displaced -1.41199368 liters
-0.00141199 m^3

96
A control system would be used to control the amount of cable let out or retracted and when. The
pressure sensor on the ROV is calibrated to give the current depth of the ROV. Live data from the
pressure sensor can be used to determine the quantity of cable that needs to be deployed. For
example initially five meters of cable would be slack. When the ROV goes below three meters
another five meters of cable is unwound. Then when the ROV reached seven and a half meters
another five meters is unwound. The amount of cable unwound will always be greater than the
depth of the ROV. This is because the ROV is unlikely to be beneath the buoy therefore the
hypotenuse length is greater than the depth. The same control will be used when the ROV is
ascending.

97
Appendix J: Electrical Schematics
Three PCB’s were designed this year to allow connection between the MyRIO in hull A and various
electronic sensors in hull B.
A compass and gyroscope are being used to provide directional data for the ROV and these were
soldered onto PCB B. Sockets were also added which allowed wires from the servos, the Thruster
Motor Controllers and the depth sensor to connect to the PCB. These sockets allowed wires to be
screwed in, in case the sensors needed to be changed in the future or if the PCB required
modification. The PCB made connection from all of the sensors to a 15-way connector which
connected to the other hull via a circular 15 core wire. This way, the MyRIO was able to connect
to 3 sensors, 2 servos and 5 motor controllers using the same PCB which measured just 65mm
long by 55mm wide as shown in Figure 72 below.
In the other hull, PCB A was used to transform from the 15 way connector to a 34 pin connector
that was synchronous with the one on the MyRIO. This allowed a single wire to connect the MyRIO
to this PCB, which relayed this connection to PCB B and thus all electronics in hull B. This process
not only cleaned up a lot of wires within both hulls, it also made connections quite easy to follow
and update when needed. PCB A was quite small (95mm long by 45mm wide) and was able to be
tucked away neatly next to the battery in hull A. Figure 73 below, displays PCB A where
connections have been highlighted.

98
Figure 72: PCB B which resides in HULL B and connects to all sensors, servos and motor controllers
Figure 73: PCB A which resides in HULL A and connects HULL B components to the myRIO

100
Appendix K: Detailed Software Information
This section, covers the different software components of the control system and explains in detail
how each is employed to carry out specific tasks. These specific tasks are then linked to tackle each
objective specified at the beginning of Section 7. A few terms that will be used throughout this
section are:
VI: A piece of program written in LabVIEW and made up of Sub-VI’s
Sub-VI: A code snippet that performs a single function and forms part of a bigger program
Library: A set of drivers that allow the myRIO to connect to specific hardware
Network Protocol: A Library that allows network communication using Ethernet
Wireless control from user PC
Deciding on a network protocol to maximise data transfer and reliability
Connecting to the ROV over the proposed Ethernet and wireless link required that data be
communicated between the user (host) and ROV (target) using a network protocol that is designed
to run in the program background. LabVIEW offers a few different network protocols that are
designed differently to cater to different data requirements.
Last year’s design employed network streams
for this task, due to high speeds and reliability
offered by this protocol. Furthermore, network
streams are very easy to set up, as shown in
Figure 74, with a Sub-VI on each side of the
connection to read and write data respectively.
Figure 74: Host and Target loops for network streams

101
A wide array of data types are supported by this protocol and can be transferred without the need
for conversion. Thus, taking from last year’s design, network streams were employed for this
year’s design. It must be noted here that all networking within LabVIEW is uni-directional. The
resulting 4 connections and their origins are highlighted in Table Y below. Data sent from each
side, must be read at the opposite end before it may be used within the program.
Table 16: Explanation of the required network connections between host and target
Connection # Origin Description
01 Host Write and send user commands to target
02 Target Write and send video stream to host
03 Target Write and send sensor data to host
04 Target Write and send user interface indicators (LED states) to host
The first system test performed at Maindy pool was the first instance where host to target
networking was validated. A constant video stream was established, sensor data was relayed to
the host and user commands were received at the target side.
After a successful initial connection however, a significant lag was observed in the transfer of data
between host and target. This lag caused the video stream to drop continuously and even caused
an uneven thruster response to user commands. This was also associated with the sideways drift
caused during straight line motion, as discussed in Section 3.2.
The above effect was observed on all the PC’s used during the test, thus the attribute was not
limited to any one host. To eradicate the adverse effects on a short-term basis, the video stream
was turned off, so that only user commands and sensor data were exchanged between host and
target. This offered a significant improvement in the lag observed. In-depth investigation
performed following the pool test indicated that a reduction in video resolution alleviated the

102
negative lag effect considerably. A relationship was thus determined, between the lag observed
and the amount of data being transferred at any given time.
A high resolution for the video stream was a requirement to allow the user to navigate the ROV
accurately. Thus, it was decided to investigate different network protocols that would allow high
resolution video transfer more efficiently. This was paired with an effort to make other data
transfer more efficient too.
To determine which network protocol was most appropriate for the project, a simple test was
setup that was identical, except for the network protocol employed. The test involved the transfer
of a constant video stream whilst a set of 500 Boolean user commands were relayed to the target
to switch the state for an LED. To replicate test conditions, the camera was placed to record a
video on a computer screen which was
restarted between tests. Using the software
LAN Speed Test by Totusoft, shown in Figure
75 left, numerical data was obtained for the
transfer speeds observed during 3 iterations
of each test. These were then averaged to
give a more accurate score. Alongside this,
the video stream was observed intently to determine any lag present. This was used to collect real
world data to complement numerical data gathered. The test was performed for four of the
available network protocols within LabVIEW. The other protocols were disregarded for their
Figure 75: Numerical data for transfer speeds using LAN Speed Test
4

103
limited application within streaming of data. The results for the series of tests have been
summarised in Table 17 while Figure 76 gives a visual representation of transfer speeds observed.
Table 17: Summary of transfer speeds for labVIEW network protocols
Protocol Description
Network Stream No data loss but transfer speeds slower than TCP and UDP
TCP Second fastest method with a reliable connection and no data loss
UDP Fastest transfer speeds but with missing frames
Network Shared
Variable
Slowest transfer speeds with missing frames
Figure 76: Comparison of transfer speeds for networking protocols in LaabVIEW
The test included Network streams for completeness and the behaviour observed was similar to
the pool test in Maindy.
The results of the tests showed that global variables were the slowest method for constant stream
of data. With a built-in stream feature turned on, there was a marked improvement in
performance of these variables. However, because global variables were designed to be used with

104
numerical data, there use for transfer of video was inefficient. This was because each image
needed to be converted to numerical format for transfer and the process reversed on the opposite
site. Thus, they were eliminated as a choice within the video stream function.
UDP is an industry standard networking protocol and finds wide use within streaming functions.
Tests revealed that this was the fastest protocol within LabVIEW and seemed an obvious choice.
Missing frames were observed during the UDP test. However, for the purpose of video streaming
or a constant relay of movement commands, data missed was not considered to be an issue. The
protocol only allowed transfer of string (text) data and any other data form needed to be
converted prior to and following transfer. This increased the difficulty in setting up connections
but the marked improvement in transfer
speeds justified this effort. The only issue
associated with UDP was that a connection
could only be initiated where data was being
generated. This meant that to send video data
to the host, the connection would have had to
be initiated on the target, with the converse
being true for user commands. A fixed IP
address for the destination was required for
each connection. This meant that only one PC could be used to control the ROV after the program
was compiled. Because the ROV was being built for a customer, this restriction meant that the
program could never be tested on their PC if it was developed on ours. Thus, UDP too was
eliminated as a choice of network protocol.
Figure 77: Host and Target loops for TCP

105
TCP is slower only to UDP, with significant performance increases compared to network streams
(which are also based on TCP). TCP offers lossless communication and is used widely for all kinds
of network connections. Like UDP, TCP requires data being transferred as string type. However,
unlike UDP, TCP (and so network streams) can be initiated on either end of the connection by only
supplying the IP address of either side. It was clear then, that TCP was an ideal choice for network
communication. The same four network streams were replaced with TCP and a fixed IP address
for the target was specified. Code was added for the conversion of data for transfer and the
updated code has been shown in Figure 77 above.
Setting up WI-FI router
A WI-FI router was to be placed on the buoy to increase the range of operation for the ROV system.
This router connected to the ROV via a 25m Ethernet cable and to the user via wireless Ethernet.
The settings for the router were changed from default to facilitate its function within the project.
At the start of the project, an IP address was defined for the Ethernet adapter on the ROV. To
explain the WI-FI settings, an IP address must first be discussed. The IP address is divided in two
parts as shown below:
169.254.27.143
The part in red represents the network prefix and is not relevant. The part in green represents a
range which can be utilised by devices to form a stable network and transfer data. It was possible
to set the IP address for the router to be the same as that for the ROV Ethernet adapter. This
meant that although the user was communicating with the router, the connection was routed
forward to the ROV to allow controlling it. A stable network was then created by limiting the IP

106
addresses that can be taken up by connecting PC’s. This range was set to be 169.254.27.140-150
and meant that only up to ten IP addresses could be taken up by a connecting host. Number of
connections was limited to one for network security and to prevent interference in the mission.
The name of the router’s connection was changed to “UAV Submarine” to help in its identification
and a password was set too.
Following the setup of the router, a number of tests were performed to validate the stability of
connection as well as range. This was done by setting up a video stream and the speed affects
observed when the distance between router and host was varied. A maximum operable range of
about 20m in an open environment was determined and was deemed sufficient for the project.
Further antennae could be added to improve connection but was not required as yet.
When the third pool test was performed (Section 9), there was a constant issue observed with the
router where the connection kept dropping out. The connection was shifted to wired Ethernet to
continue the test and the router issue was investigated after the test to save time. It was found
that following a software update that had been performed before the test, the IP for the Ethernet
adapter on the ROV had somehow changed. This was believed to be due to the adapter being
recognised as a new device following the update. This change in IP address (to 169.254.191.69)
meant that the router was no longer within the same network as the adapter and connection was
thus difficult. A simple solution to the problem was to replicate the adapter IP for the router and
change the network range to match this. Tests were performed following this change and
connection was found to be reliable and secure.

107
ROV Camera and LED
Video Recording
Specification required that the user was able to identify species of mussels on the sea floor. It was
assumed that the user would want to maintain a record of the species found. Therefore, allowing
the user to record video and images instead of just displaying them seemed like a logical addition
to ROV functionality from last year. The switch to TCP meant that high resolution video could be
transmitted over the network without issues. As video recording is a processor intensive task, it
was decided to save videos and images at the host end. The optimum rate for video recording is
30 frames per second and the webcam used, supported this framerate.
LabVIEW allows the ability to run a loop at a particular speed and a timed loop is used for this
application. To get a framerate close to 30 per second, the timed loop was repeated every
33.33ms. A frame of video or image is grabbed in each iteration of the loop and the loop runs 30
times every second. This image was compressed to 75% quality and then transferred to the host
at the same speed by utilising buffers built into TCP connections.
On the host side, things are a bit more complicated. To compile a video from any number of
images, a codec is required. These are openly available for windows and LabVIEW is preloaded
with quite a few. This is one of the reasons why video recording and saving could not have taken
place on the myRIO itself as there is a great lack of codecs for the myRIO. To determine the right
choice, a number of codecs were used to record a fixed length file. The files were then compared
for size and the resulting quality each offered. The codec selected, “Cinepak Codec by Radius”,
offered the best quality at the smallest file size. The codec allowed saving an AVI format for the

108
video which is highly popular and can be played on almost all modern devices. This added further
value to the video recording endeavour.
As images are transferred to the host, they are
continuously added to a buffer for processing.
These may then be recorded to a video file or
removed from buffer depending on the user’s
input. The recording processes follows three
main steps as shown in Figure 78:
The first step involves opening a new AVI file.
This creates a reference to available space on the PC’s hard drive that can be used to save the file.
The file path to save the resulting files must be set manually. A new file can be created by the user
at any time by using the appropriate button within the recording controls. Each of the buttons is
associated to a different step and the buttons are used by the user to navigate the steps as
required. As a new file is created, the button is disabled and the record/pause button is enabled.
This is done by setting the properties for the two buttons and the practice prevents the user from
creating more than one file at once.
The second step initiates when the record button is pressed. At this point, an image from the
buffer is added to each frame of the video instead of being deleted. This repeats till the button is
pressed again to pause recording. This button press enables the save file button but does not
disable the record button. The user may choose to save the file to stop adding more frames to it.
Alternatively, the recording may be resumed by repressing the button. The video picks up where
Figure 78: 3 steps in saving images to AVI file

109
it left off and adds the new frames. This process may be repeated as many times as required by
the user before saving the file.
The third step stops the recording process and finalises the file. The file is closed and may not then
be accessed from within the program. To restart recording, a new file must be created and the
appropriate steps followed. The file is saved to a location specified within the program. In this
case, all media saved goes to a “Media” folder with the main program folder. Here videos and
images are organised by the time they were recorded. This is done by adding a time stamp to the
filename when it is recorded. This automatically sorts the files to display the latest ones on top
and helps keep the media organised. This folder has been included on the CD.
The program allows the user to record as many videos as needed and they are all organised by use
of time stamps. The only limitation to this is the size of the hard drive on the host PC and that is
rarely a limitation in today’s age.
Saving Screenshots
Along with recording video, the user is also able to save screenshots of the current view being
displayed on screen. This uses a simple Sub-VI provided by LabVIEW and outputs a JPEG image file
to the media folder with a timestamp. To save a screenshot, the screenshot button must be clicked
on the screen. Again, no limitations have been placed on the number or frequency of screenshots
saved.

110
Camera LED
An LED spotlight was added to the camera arrangement this year. This was done to improve vision
by increasing visibility underwater, especially in low light conditions. For this purpose, a 4.5W watt
energy saver LED was used whose output was equal to a 20W bulb but at a fraction of the power
consumption. The LED spotlight was modified in-house to reduce its dimensions and enable a
compact fit in the hull. PCB C was designed to allow switching the LED state from within the
program. Further details for this
PCB have been provided in
Appendix K: Detailed Software
Information. Figure 79 left, shows
the camera and LED arrangement
along with PCB C mounted on a
polycarbonate plate to secure
within Hull A. The Sub-VI required
to operate the LED was very simple.
A single toggle switch was added next to the recording controls to change the LED state. At first,
it was attempted to switch states using the keyboard or controller. However, buttons on these are
designed to be hold switches and only retain their state when the button is held. This was an
unnecessary chore for the user and it was decided that the simple toggle switch was easily
accessible on screen. An LED alongside the switch displays the current state for the button and
switches with the spotlight. This arrangement is shown in Figure 23, Section 7.5.2.
Figure 79: ROV camera, LED and PCB C

111
Sediment Sampler control program
The sediment sampler mechanism has been discussed in detail in Section 6. The arrangement
involves the use of two servos; one for vertical movement of the syringe assembly, the other to
rotate the cap into position. Servos are controlled by using PWM signals. The myRIO has a number
of ports that support this signal and two of these, PWM0 and PWM1 on MXP A (Section 7.2.2), will
be utilised for the sediment sampler arrangement.
Servos rotate when there is a difference between current and target
position. The servo’s movement may be divided into a series of
steps. Each step can have a fixed increment, which does not need to
be limited to one. By using the appropriate steps and increment
combo, the servo can be made to move a certain angle very
accurately. Setting a loop speed determines how quickly the angle
is moved. By running through a series of manual simulations, the
required rotation angle was determined for each servo. Then by experimenting with different
step/increment combos, a smooth movement can be attained between current and targets
positions at the required speed. Figure 6 above shows the necessary controls to undertake this
process. When the position, loop speed, number of steps and increment were determined for each
servo, a state machine was created to run through a series of required states for the sampler
assembly. These were:
 Move to initial position and lock motion here
 Rotate the cap out of the way of the syringe
 Lower the syringe to collect a sediment sample
 Raise the syringe back up following collection
 Rotate the cap under the syringe for capping
Figure 80: Servo positioning

112
 Lower the syringe into the cap to secure and lock motion
Figure 81 below, shows one of the states for the servo. The total states are displayed in the upper
left corner as the number of iterations for the loop.
Figure 81: State machine for sediment sampling mechanism
For each state, a different initial and final position were determined following manual alignment
by hand. These were transferred between states by use of local variables within the VI. These are
displayed in orange as “Position out” and “Position out 2” in Figure 81 and act as a feedback node
following a state.
To inform the user for when a sample is being collected, an LED indicator was lit up on screen. The
state of this LED indicator was connected to the various
states of the state machine for the sediment sampler. The
state of the LED was displayed to the user’s screen by use
of a global variable. This is shown with an “earth” icon at
the left edge of the green icon in Figure 81. This LED was
left high for all states except “End” whereby a second LED
indicated the completion of sample collection. A global
Figure 82: Front Panel displaying condition of
sediment sampler

113
variable was not required for this LED as it was situated outside the state machine and a regular
connection was sufficient. The condition of the sediment sampler mechanism is displayed to the
user on screen, as shown in Figure 82.
Motion Control
ROV Coordinate and Thruster Labelling
The control program allows the user to control the motion of the ROV in all three linear axis, as
well as the z-rotational axis. The coordinate system adopted during developing the control
program is illustrated by Figure 83.
Figure 83: Coordinate system adopted during development of the control program.
Motion in each axis was achieved by activating specific combinations of thrusters. Table 18 details
which of the five thrusters need to be activated in order to achieve motion in each axis. Figure 84
illustrates which number was assigned to each thruster.

114
Table 18: Thrusters activated during motion in each axis.
Axis Active
Thrusters
Direction
+X 1 & 4 Forward
-X 2 & 3 Forward
+Y 1 & 2 Forward
-Y 3 & 4 Forward
+Z 5 Forward
-Z 5 Reverse
Z-Rotational (CW) 2 & 4 Forward
Z-Rotational
(ACW)
1 & 3
Forward
Figure 84: Thruster number assignment.
Motion Control with Sensor Feedback
An attempt was made to develop a feedback control loop which would enable the ROV to correct
its motion in response to any environmental influence, such as tidal currents or debris. Two control
loops were developed, one to control the ROV’s vertical velocity and one to control the ROV’s
rotational velocity about the Z-axis.

115
Figure 85 and Figure 86 illustrate the block diagrams of the vertical and rotational control loops
respectively.
Figure 85: Vertical velocity control loop.
Figure 86: Rotational velocity control loop.
ROV Vertical Transfer Function
The dynamics of the ROV in the Z axis was estimated as follows:
𝐹𝑇(𝑡) = 𝐹𝐷(𝑡) + 𝐹𝐼(𝑡)
whereby: 𝐹𝑇(𝑡) is the force from thruster,
𝐹𝐷(𝑡) is the drag force resulting from the motion of the ROV through the water,
𝐹𝐼(𝑡) is the inertial force resulting from the acceleration of the ROV.

116
It was assumed that:
𝐹𝑇(𝑡) = 𝐶 𝑇 𝑉𝑇(𝑡);
𝐹𝐷(𝑡) = 𝐶 𝐷
𝑑𝑧(𝑡)
𝑑𝑡
;
𝐹𝐼(𝑡) = 𝑀
𝑑2 𝑧(𝑡)
𝑑𝑡2
.
whereby: 𝑉𝑇(𝑡) is the thruster input voltage,
𝑧(𝑡) is the position of the ROV on the Z axis.
𝑀 is the mass of the ROV which is roughly 16 kg. 𝐶 𝑇 was calculated using the thruster data
sheet provided by Blake et al. (2014). Assuming a linear relationship between the force
applied by the thruster and its input voltage, 𝐶 𝑇 was estimated to be 0.77 N/V. 𝐶 𝐷 was
calculated using the results from CFD analysis performed by Blake et al. (2014). Assuming a
linear relationship between the ROV’s velocity and the resultant drag force, 𝐶 𝐷 was estimated
to be 37.8 N/ms-1:
𝐶 𝑇 𝑉𝑇(𝑡) = 𝐶 𝐷
𝑑𝑧(𝑡)
𝑑𝑡
+ 𝑀
𝑑2
𝑧(𝑡)
𝑑𝑡2
𝐶 𝑇 𝑉𝑇(𝑠) = 𝑠𝐶 𝐷 𝑧(𝑠) + 𝑠2
𝑀𝑧(𝑠)
𝑧(𝑠)
𝑉𝑇(𝑠)
=
𝐶 𝑇
𝑠𝐶 𝐷 + 𝑠2 𝑀
=
0.77
37.8𝑠 + 16𝑠2
ROV Rotational Transfer Function
The dynamics of the ROV in the Z-rotational axis was estimated as follows:
𝑀 𝑇(𝑡) = 𝑀 𝐷(𝑡) + 𝑀𝐼(𝑡)
whereby: 𝑀 𝑇(𝑡) is the turning moment applied by two thrusters,
𝑀 𝐷(𝑡) is the drag force resulting the ROV rotating in the water,
𝑀𝐼(𝑡) is the inertial force resulting from the angular acceleration of the ROV.

117
It was assumed that:
𝑀 𝑇(𝑡) = 2𝐶 𝑇 𝑉𝑇(𝑡)(𝑦 sin 𝛼 + 𝑥 cos 𝛼);
𝑀 𝐷(𝑡) = 𝐶 𝐷
𝑑𝜃(𝑡)
𝑑𝑡
.;
𝑀𝐼(𝑡) = 𝐼
𝑑2 𝜃(𝑡)
𝑑𝑡2
.
whereby: 𝑉𝑇(𝑡) is the thruster input voltage,
𝜃(𝑡) is the angular position of the ROV about the Z axis.
Figure 87 illustrates how 𝑥 is the distance along the X-axis from the outlet of any horizontal
thruster to the ROV’s centre of rotation, assumed to be thruster 5’s axis of rotation. This was
measured as 0.060 m. 𝑦 is the distance along the Y-axis from the outlet of any horizontal thruster
to the ROV’s centre of rotation. This was measured to be 0.195 m. 𝛼 is the angle between the X-
axis and the axis of rotation of a horizontal thruster. This was manufactured to be 45⁰.
Figure 87: ROV thruster geometry.

118
𝐼 is the polar moment of inertia of the ROV, which was roughly estimated to be 2.3 kg.m2. 𝐶 𝑇
was calculated using the thruster data sheet provided by Blake et al. (2014). Assuming a linear
relationship between the force applied by the thruster and its input voltage, 𝐶 𝑇 was estimated
to be 0.77 N/V. 𝐶 𝐷 was calculated using the angular velocity measurements acquired from the
second pool test. The maximum angular velocity was found to be 94⁰/s. At this velocity, the
moment applied by the two active thrusters was 13.1 Nm. Assuming a linear relationship
between the ROV’s angular velocity and the resultant drag force, 𝐶 𝐷 was estimated to be 0.067
N/ms-1:
2𝐶 𝑇 𝑉𝑇(𝑠)(𝑦 sin 𝛼 + 𝑥 cos 𝛼) = 𝑠𝐶 𝐷 𝜃(𝑠) + 𝑠2
𝐼𝜃(𝑠)
𝜃(𝑠)
𝑉𝑇(𝑠)
=
2𝐶 𝑇(𝑦 sin 𝛼 + 𝑥 cos 𝛼)
𝑠𝐶 𝐷 + 𝑠2 𝐼
=
2 × 0.77 × (0.195 sin 45 + 0.060 cos 45)
0.067𝑠 + 2.3𝑠2
𝜃(𝑠)
𝑉𝑇(𝑠)
=
2.60
0.067𝑠 + 2.3𝑠2
Simulations using LabVIEW
LabVIEW’s Control Design and Simulation module allows the user to construct a virtual control
system, then assess the system’s response to various inputs and adjustments to the controller’s
parameters. The models illustrated in Figure 85 and Figure 86 were assessed using this method to
determine the optimum controller gains. Table 19 summarises the findings.
Table 19: Optimum controller gains based upon LabVIEW simulations.
Control Loop KP KI KD
Vertical Motion 650 300 0
Rotational
Motion
10 2
0

119
Figure 88 illustrates the predicted response of the vertical motion control loop to a step velocity
input of 0.2 ms-1.
Figure 88: ROV response to a vertical, 0.2 ms-1
, step input.
Figure 89 illustrates the predicted response of the rotational motion control loop to an external
turning moment of -40 Nm, applied at 5 seconds.
Figure 89: ROV response to a turning moment of 40 Nm applied at 5 seconds.
Implementation of Feedback Control
Upon implementation of the control loops it was found that neither the depth sensor nor the
compass were particularly precise. The reading from the depth sensor fluctuated by approximately
±0.25 m once calibrated, whilst the compass reading had an error of ±1⁰. A relatively large time
0
0.05
0.1
0.15
0.2
0.25
0 1 2 3 4 5 6 7 8 9 10
VerticalVelocity/m/s
Time /s
-1.8
-1.6
-1.4
-1.2
-1
-0.8
-0.6
-0.4
-0.2
0
0.2
0 1 2 3 4 5 6 7 8 9 10
RotationalVelocity/deg/s
Time /s

120
step of 25 ms was required between successive sensor readings to allow updated speed
commands to be sent to the thruster controllers. Because the control loop measured velocity by
differentiating these sensor readings, the resultant error in the measured velocity was 10 ms-1 in
the vertical axis and 40⁰/s in the rotational axis. As such, the motors were being continually
activated in order to counteract for perceived changes in velocity.
Time constraints prevented further development of the control loops to alleviate this issue. It was
planned to incorporate accelerometer and gyroscope readings into the control loops to achieve a
more accurate velocity measurement. It was also planned to implement signal conditioning
methods to remove some of the noise from the depth sensor and compass readings.

121
Appendix L: Thruster Battery Specification
Table 20 summarises the specification of an individual thruster (SeaBotix Inc., 2007).
Table 20: Specification of an individual thruster.
Nominal Input Voltage /V 19.1
Max. Continuous Current /A 4.25
Max Surge Current (30 s) /A 5.8
A maximum of three thruster could be active at any one point in time. One thruster would be
controlling the ROV’s vertical motion and two thrusters would be controlling the ROV’s horizontal
motion. The maximum continuous current from the power supply was therefore calculated as
such:
𝐼max 𝑐𝑜𝑛𝑡. = 4.25 × 3 = 12.75 𝐴
A minimum mission duration of 45 minutes was specified in the project brief. Using a safety factor
of 2, the required battery capacity was calculated as such:
𝐸𝑡ℎ𝑟𝑢𝑠𝑡𝑒𝑟 = 2 × 0.75 × 12.75 = 19.125 𝐴ℎ ≈ 20000 𝑚𝐴ℎ
Table 20 summarises the specification of the battery identified as the most suitable for this
application (Hobby King Ltd., 2014). Connecting four of these batteries in parallel provided 20000
mAh of capacity at a voltage close to each thruster’s nominal input voltage of 19.1 V.
Table 21: Specification of an individual battery.
Nominal Output Voltage /V 22.2
Energy Capacity /mAh 5000
Max. Continuous Current /A 100
Length × Width × Height
/mm
145 × 50 × 50
Mass /kg 0.765

122
myRIO Battery Specification
Table 22 summarises the specification of the myRIO (National Instruments, 2013).
Table 22: myRIO specification.
Minimum Input Voltage /V 6
Maximum Input Voltage /V 16
Max. Continuous Input Power
/W
14
Idle Input Power /W 2.6
The battery specification was based upon the myRIO’s maximum continuous input power as it was
anticipated the battery would eventually need to power additional hardware.
It was decided that a 3 cell LiPo battery would be most suitable for this application due to its 11.1
V nominal output voltage. This was in the centre of the myRIO’s operating voltage range. The
current drawn from the battery during operation of the myRIO at maximum power was calculated
as such:
𝐼 𝑚𝑎𝑥 =
14
11.1
= 1.26 𝐴
A minimum mission duration of 45 minutes was specified in the project brief. Using a safety factor
of 2, the required battery capacity was calculated as such:
𝐸 𝑚𝑦𝑅𝐼𝑂 = 2 × 0.75 × 1.26 = 1.89 𝐴ℎ ≈ 1900 𝑚𝐴ℎ
Table 23 summarises the specification of the battery identified as the most suitable for this
application (Hobby King Ltd., 2014).

123
Table 23: Specification of an individual battery.
Nominal Output Voltage /V 11.1
Energy Capacity /mAh 2200
Max. Continuous Current /A 44
Length × Width × Height
/mm
103 × 24 × 33
Mass /kg 0.188

124
Appendix M: List of User Commands
Table 24: List of user commands.
Command
Action
Keyboard Xbox Control Pad Mouse
Ascend W LT
Descend S RT
Forward UP Arrow LB & Left Analog Stick Forward
Reverse DOWN Arrow LB & Left Analog Stick Backward
Left LEFT Arrow LB & Left Analog Stick Left
Right RIGHT Arrow LB & Left Analog Stick Right
Anticlockwise A Right Analog Stick Left
Clockwise D Right Analog Stick Right
Micro Sensor 7 B (Red)
Sediment Sampler 8 X (Blue)
Spot Light On/Off
Click Spot Light
On/Off Switch
Vertical Thruster
Power
Adjust Vertical
Thruster Power
Knob
Create New Video
File
Click Create Video
Icon
Record Video
Click Record Video
Icon
Pause Video
Click Record Video
Icon
Save Video File
Click Save Video
File Icon
Capture and Save
Image
Click Screenshot
Icon
Activate Xbox
Control Pad
Click Joystick
On/Off Icon
Stop Control
Program
ESC Back Click ROV Stop Icon

UAV report vFINAL

More Related Content

What's hot (8)

Viewers also liked (11)

Similar to UAV report vFINAL (20)

UAV report vFINAL