1. SANTA CLARA UNIVERSITY
Department of Mechanical Engineering
Date: June 16, 2015
I HEREBY RECOMMEND THAT THE THESIS PREPARED UNDER MY
SUPERVISION BY
Arjun Sukumar Menon
ENTITLED
Autonomous Control of ROV with
Coordinated Surface Vessel Operations
BE ACCEPTED IN PARTIAL FULFILLMENT OF THE
REQUIREMENTS FOR THE DEGREE
OF
MASTER OF SCIENCE IN MECHANICAL ENGINEERING
__________________________________
Christopher Kitts, Thesis Advisor
__________________________________
Drazen Fabris, Chairman of Department

2. Autonomous Control of ROV with
Coordinated Surface Vessel Operations
By
Arjun Sukumar Menon
GRADUATE MASTER THESIS
Submitted in Partial Fulfillment of the Requirements
For the Degree of Master of Science
in Mechanical Engineering
in the School of Engineering
Santa Clara University, 2013
Santa Clara, California

3. iii
Autonomous Control of ROV with Coordinated
SurfThesisace Vessel Operations
Arjun Sukumar Menon
Department of Mechanical Engineering
Santa Clara University
2013
Abstract
Remotely Operated Vehicles (ROV) are tethered underwater robots that have been used
since the 1950s for various applications such as ocean exploration, oil pipeline repairs,
collecting samples etc. One of the greatest challenges for ROVs is the ability to navigate
them effectively in order to maintain bearing, depth, follow a straight line, follow a path
etc. For this research project, the Santa Clara University’s Triton ROV was converted to
support computerized control, an acoustic tracking system was integrated in order to
track Triton’s position underwater, and several automated controllers were implemented
to improve navigation and improve operational effectiveness.
With the use of this control system, the pilot can engage assisted piloting modes such as
heading lock and depth lock. The path lock mode locks the path to be traversed by the
ROV. If any side drifts occur due to disturbances such as underwater currents, the ROV
will compensate and return to the locked path. The autonomous mode does point to point
navigation based on GPS points and depth.
The kayak coordinated mode features the ability for the Kayak to track the ROV by
traveling on the X-Y plane above the ROV. The ROV in slave mode can do the inverse
which is to track the kayak underwater based on a user specified depth. These modes
were experimentally verified and tested in the field and are an integral part of improving
the operational effectiveness of ROV operations as a part of the Santa Clara University
robotics program.
Keywords: Triton digital controller, Triton kayak coordinated control.

4. iv
Acknowledgements
I would like to first thank Professor Chris Kitts. Without his guidance and support this
thesis would not have been taken as far as it had. His support always kept my motivation
to the highest level and led me to the answers I was looking for.
I would also like to thank Thomas Adamek. For the past year and a half, Thomas
has been a huge support in terms of logistics and planning. Without his help and support,
the multiple days of deployment and testing would not have been possible.
I’d like to thank Chase Traficanti, Mike Vlahos and Sreekanth Dayanidhi from SCU RSL
for all their support with acoustic tracking, software debugging and kalman filters. I’d
like to also thank the rest of the SCU RSL Marine robotics team who helped me out with
deployments.
I would also like to thank William Kirkwood and his colleagues from Monterey Bay
Aquarium Research Institute for their support and guidance.
Lastly, I’d like to thank my family and my friends for their support during this last year.
Without their backing this would not have been possible. As busy as this last year has been
their understanding made it possible to get everything completed without losing my
mind.

5. v
Table of Contents
Abstract…………………………………………………………………………………...iii
Acknowledgement…………………………………………………………..……………iv
Table of Contents..........................................................................................................…...v
List of Figures….………………………………………………………………...………vii
Chapter 1
1.0 Introduction…………………………………………………………………...............1
1.1 ROV Operations………………………………………………………........................7
1.2 Triton ROV…………………………………………………………………………...7
1.3 Project Statement……………………………………………………………………..9
1.4 Readers Guide……………………………………………….....................................10
Chapter 2
2.0 System Description…………………………………………………………………..11
2.1. Triton…………………………………….…………..................................................12
2.2 Robotic Kayak……………………………………………………….........................13
2.3 Acoustic Tracking System………………………………………………………...…15
2.3.1 Filtering Approach…………………………………………………….…..19
2.3.2 Filtering Results…………………………………………………………...21
2.4 Software Architecture and Communication .…………………..………… .. ……….24
Chapter 3
3.0 Control System………………………………………………………………………25
3.1 ROV Manual Control…………………………………………………………….…..26
3.2 ROV Pilot Aids………………………………………………………………………27
3.2.1 Heading lock………………………………………………………………28
3.2.2 Depth lock…………………………………………………………………30
3.2.3 Path lock…………………………………………………………………..32
3.3 ROV Autonomous Navigation……………………………………………………….34
3.4 Kayak Control mode…………………………………………………………………37
Chapter 4
4.0 Field Testing Data…………………………………………………………………....39
4.1 Heading lock………………………………………………………………………....39
4.2 Depth lock……………………………………………………………………………40
4.3 Point to Point ROV Controller……………………………………………………….40
4.4 Path lock……………………………………………………………………………..42
4.5 Point to point kayak Controller………………………………………………………44
4.6 Point to Point: Kayak tracking ROV…………………………………...……………46
4.7 Summary……………………………………………………………………………..48
Chapter 5
5.0 Conclusion…………………………………………………………………………...49
5.1 Summary and Conclusion……………………………………………………………49
5.2 Future Work………………………………………………………………………….50

6. vi
REFERENCES...............................................................................................................................52
APPENDICES……………………………………………………………………………………55
APPENDIX A……………………………………………………………………………56
APPENDIX B……………………………………………………………………………63

7. vii
List of Figures
Figure 1.1: William Beebe sitting on the Bathysphere……………………..…………….……1
Figure 1.2: Bathyscaphe Trieste in the year 1960……………………….…..………...……...2
Figure 1.3: Famous Alvin research manned submersible…………….………………………2
Figure1.4: Deepsea Challenger……………………………………………………..…………...3
Figure1.5: Triton36000………………………………………………………………….………..4
Figure1.6: NOAA’s ROV Hercules exploring the remains of the Titan………………….…5
Figure1.7: Millennium ROV was used to cap the BP oil spill at Gulf of Mexico……….…6
Figure 1.8: ROV Ventana was built for the Monterey Bay Aquarium Research Institute
by International Submarine Engineering……….…………..……….…………6
Figure1.9: Triton ROV in deployment at Lake Tahoe…….…………………………..………8
Figure2.1: System level overview of Triton during operation with Kayak tracking…..…11
Figure 2.2: Triton ROV makes use of 4 thrusters for propulsion…………………..………12
Figure 2.3: Triton ROV system level diagram……………………………..…………………13
Figure2.3: Robotic Kayak used to track ROV……………………………...……………...…14
Figure 2.5: Acoustic Transducer below base station with Triton in the background……15
Figure 2.6:(a) Acoustic Transducer (b) Signal processing unit (c) beacon………………16
Figure 2.7: Acoustic tracker system level diagram and hardware setup………………….16
Figure2.8: Easytrak Acoustic tracking Software User Interface………...…………………18
Figure 2.9: Raw Performance of Acoustic tracker with many outliers……………………22
Figure 2.10: Filtered X axis performance of acoustic tracker.…………….…………….…22
Figure 2.11: Filtered Y axis performance of acoustic tracker.………………….…….……23
Figure 2.12: Filtered Performance of Acoustic tracker………………………………….….23
Figure2.13: System Communication…………………………………………………………...24
Figure 3.1: Triton system control modes………………………………………………………25
Figure 3.2: ROV and Kayak frames.…………………………………………………………...26
Figure 3.3: Manual mode…………………………………………………………..……………27
Figure 3.4: Assisted: Heading………………………………………………………………..…28
Figure 3.5: Desired heading and current heading in global coordinates…………………29
Figure 3.6: Heading lock simulation performance……………………………………..……29

8. viii
Figure 3.7: Assisted Depth………………………………………………………………….…..30
Figure 3.8: Desired depth versus measured depth in global coordinates………………...31
Figure 3.10: Assisted Path lock mode………………………………………………………….32
Figure 3.11: Cross track control strategy………………………………………………..……33
Figure 3.12: Simulated performance of path lock control…………………………………..34
Figure 3.14: Point to point navigation………………………………………………………...35
Figure 3.15: Desired point versus measured point in global coordinates………………..36
Figure 3.16: Simulated performance of path lock control……………………………..……37
Figure 3.17 Point to point navigation………………………………………………………....38
Figure 3.18: Desired point versus measured point in global coordinates………..………38
Figure 4.1: Heading lock……………………………………………………………………..…39
Figure 4.2: Depth lock……………………………………………………………………..….…40
Figure 4.3: Point to point mode – X vs. Time…………………………………………………41
Figure 4.4: Point to point mode – Y vs. Time…………………………………………………41
Figure 4.5: Point to point mode – XY plot………………………………………………….…42
Figure 4.6: Cross track controller: Ect vs. Time………………………………………..……43
Figure 4.7: Cross track controller: X, Y plot of desired path vs. actual path…………….43
Figure 4.8: Kayak point to point controller - X vs Time………………………………….…44
Figure 4.9: Kayak point to point controller - Y vs Time……………………….……………45
Figure 4.10: Kayak point to point controller - XY plot……………………………...………45
Figure 4.11: Kayak tracking ROV - X vs. Time………………………………………………46
Figure 4.12: Kayak tracking ROV - Y vs. Time………………………………………….……47
Figure 4.13: Error plot for distance between ROV and Kayak……….……………………47

9. 1
1.0 Introduction
It has been said that we know less about the landscape of our ocean than we do about the
moon’s. During the 1850s and 1860s pressure grew to explore the ocean because
scientific expeditions began to show ocean life below 1 kilometer depth. These
expeditions began to show life forms that were never seen before and were completely
unfamiliar. There was also economic pressure to explore the deep sea since companies
wanted to lay submarine cables for communication between Europe and America by
telegraph; to do this however they needed improved knowledge of the deep sea [3].
Although humans have been trying to build submersibles of various forms since the
1500s, the first significant progress with underwater exploration occurred in 1934 with a
manned submersible called the Bathysphere. The Bathysphere shown in Figure 1.1 had
the ability to go down to a half mile depth [2]. It was designed by American engineer Otis
Barton, to be used by the naturalist William Beebe. Since the Bathysphere did not have
any cameras, all the information was based on human description of the ocean below
given the use of three small windows.
Figure1.1: William Beebe sitting on the Bathysphere [1][Photo Courtesy of
Ocean Explorer]

10. 2
Other milestones in deep sea explorations include the Bathyscape Trieste shown in Figure
1.2 which was completed in 1953. The Trieste used a float chamber filled with gasoline
for buoyancy and went to a new record depth of 10,300 feet [2]. The Alvin started
operation in 1964 and can carry a pilot and 2 scientists down to a depth of 14,800 feet [2].
Alvin (Figure 1.3) is still in operation today.
Figure1.2: Bathyscaphe Trieste in the year 1960 [16][Photo Courtesy of U.S. Naval
Historical Center Photograph.]
Figure1.3: Famous Alvin research manned submersible [15][Photo
Courtesy of Woods Hole Oceanographic Institution]

11. 3
Of recent note, the Deepsea Challenger (DCV 1) [17] is a 7.3 metres (24 ft) deep-diving
submersible designed to reach the bottom of Challenger Deep, the deepest known point
on Earth. James Cameron piloted the craft to accomplish this goal in the second manned
dive reaching the Challenger Deep. The submersible contains over 180 onboard systems,
including batteries, thrusters, life support, 3D cameras, and LED lighting. These
interconnected systems are monitored and controlled by a sophisticated on-board
controller. During dives, the control system records depth, temperature, pressure, battery
status, and other data, and sends it to its surface support ship at three-minute intervals.
Figure1.4: Deepsea Challenger [13][Photo courtesy of National Geographic]
One of the latest manned submersibles in development is the Triton 36000 which is being
developed by Triton Submarines and high pressure glass fabricator Rayotek Scientific.
The borosilicate glass used in the submarine gets tougher as pressure increases allowing

12. 4
the submarine to reach the deepest part of the sea; the Challenger Deep in the Mariana
Trench, at a rate of 300 feet per second. All life support is internal to the pressure hull,
and control and monitoring functions are carried out by wireless systems with touch-
screen functionality [11][12].
Figure1.5: Triton36000 [12][Photo courtesy of Triton Submarines]
ROVs are used in a wide variety of applications to include scientific discovery,
explorations, inspection and intervention operations. For example, several ROVs have
documented the Titanic wreck as shown in Figure 1.6.

13. 5
Figure1.6: NOAA’s ROV Hercules exploring the remains of the Titanic [4][Photo
courtesy of IFE/ URI /NOAA].
One of the most useful and significant application of ROVs in recent times was their use
in stopping the Deepwater Horizon oil spill. The Deepwater Horizon spill is considered to
be one of the worst oil disasters in the last few decades. NOAA estimated that up to 5000
barrels/day of oil was spilled into the ocean [3]. ROVs tracked the riser from the
wellhead to where the Deepwater horizon rig had come to rest, and ROVs helped detect
two leaks from which an estimate of oil spill rate was determined. Cameras mounted on
the ROV streamed live footage of the leak and recovery operations. In late 2012, ROVs
were again deployed in the same location to confirm that all the oil leaks were sealed off.
This is an example of how ROV technology has helped in preventing or reducing the risk
of environment related disasters.
Researchers at the Monterrey Bay Aquarium Research Institute’s have made use of ROVs
to discover new species of animals and particles in the deep sea. Frequent trips into the
Monterey Canyon using ROVs such as the one shown in Figure 1.8 have helped discover
various animal species on a regular basis.

14. 6
Figure1.7: Millennium ROV was used to cap the BP oil spill at Gulf of Mexico [20]
[Photo courtesy of Oceaneering International Inc.]
While exploring the deep water column, MBARI scientists have discovered many life
forms new to science; not just new species but whole new families of species that
represent evolutionary paths that are successful in the deep but are never seen in
shallower waters [14].
Figure 1.8: ROV Ventana was built for the Monterey Bay Aquarium Research Institute
by International Submarine Engineering [5][Photo courtesy of MBARI].

15. 7
1.1 ROV Operations
An unmanned robot is a vehicle that operates without an onboard human presence.
They can be used for many applications where it may be inconvenient, dangerous, or
impossible to have a human operator present. Unmanned robots are presently used for
bomb disposal, ground surveillance, gatekeeper/checkpoint operations, and
enhance police and military raids.
Remotely Operated Underwater vehicles (ROV) are a type of underwater unmanned
robot which use a tether to allow a human operating it to control them from a surface
ship. Large flotation packs on top of an aluminum chassis provide the
necessary buoyancy. Syntactic foam is often used for the flotation in order to withstand
deep sea pressure. Thrusters are typically used to maneuver 4-6 degrees of
freedom. Cameras, lights and manipulators are on the front of the ROV and other
instruments and tools can be carried depending on the mission. ROVs can be fully
controlled by a pilot onboard the vessel.
Automated pilot aids, such as heading lock and depth lock, also help in maneuvering the
ROV, allowing fewer operators and alleviating the load for the operators. Many advanced
pilot aids, incorporating increased levels of automation, can further improve operations
by easing operator load, improving operational efficiency, and improving performance.
Examples of this include station keeping when the pilot is working with the manipulators,
navigating to a specified location and navigating along a defined transect.
This research project has explored and implemented a range of advanced pilot aids for
Santa Clara University’s (SCU) Triton ROV.
1.2 Triton ROV
The Triton ROV, built and operated by SCU’s Robotic Systems Laboratory was
developed to support underwater visual based missions. It has been deployed in
numerous geological missions since 1999 in Monterey Bay, the Channel Islands, the

16. 8
Pacific Ocean and in Lake Tahoe. The Triton ROV is powered by two 0.5HP horizontal
thrusters and two 0.25HP vertrans thrusters. The horizontal thrusters are used to allow
forward/backward movement with desired yaw and the vertrans thrusters are configured
to allow sideways and/or vertical movement. At the front of the vehicle is a camera that
functions as the vehicles eyes. This is the image that the pilot uses as he or she flies the
ROV through the water.
Figure1.9: Triton ROV in deployment at Lake Tahoe
Triton, shown in Figure 1.9 has an operating depth of 1000 feet and has been operated
reliably by more than 250 SCU students during the past decade.
There are several operational challenges that the Triton operations team routinely
encounters. For benthic operations, it is often difficult for a pilot to maintain heading, and
even more difficult to maintain position during a defined transect. This is because the
pilot must also control depth by maintaining a low altitude above the bottom surface;
flying too high limits visibility, and flying too low leads to collisions and dust-ups.
Navigation to a specific location is also inefficient since the pilot is attempting to control

17. 9
three dimensions, one in depth, and the other two often in GPS coordinates. Overall,
these operations are often inefficient and time consuming, suffering in performance and
requiring multiple tries to complete tasks.
1.3 Project Statement
The objective of this research is to improve the operational efficiency of conducting
Triton ROV operations through automated control of the ROV and an automated surface
vehicle used for route planning and safety zone definitions.
To achieve this, several technology objectives were pursued:
 A computer control interface was developed and integrated with the ROV, the
surface vessel (a Robotic Kayak) and an external acoustic tracking system for
estimating the position of the ROV while under water. A Kalman filter was also
developed to process the noisy acoustic data.
 Several ROV control modes were implemented to include depth and heading lock,
3-dimensional waypoint control and 2 dimensional path following controller (in
which the pilot controls the depth).
 Several coordinated ROV/Kayak control modes were implemented. These
included using the kayak to specify the (X,Y) position of navigation points,
slaving the kayak’s position to be above the ROV and slaving the ROV to be
under the kayak.
 Field experiments were conducted to characterize and verify the performance of
these controllers and to validate them during a real science mission for which
operational efficiency was critical.
All of the implemented capabilities were motivated by stated needs of RSL’s ROV
operations and science collaborators based on previous field operations. Field results
showed that these capabilities were successfully achieved and that they improved RSL’s

18. 10
ability to conduct ROV operations.
1.4 Reader’s Guide
This thesis is divided into five chapters and is structured as follows: The first chapter
provides an introduction to ROVs and its applications and in specific the ROV that we
will be using for the experimental test bed. The chapter also discusses the motivation for
this project and lists the objective of the thesis.
The second chapter gives an overall view of the system and goes into the details of the
experimental test bed. It provides a basic summary of the different control modes
available. It also includes a discussion of the communication architecture of the system.
The third chapter goes into the control technique used and reviews the computer
simulations and how the tests were conducted with a brief explanation of the test setup
and procedures.
The results of field testing are shared in the fourth chapter. The testing conditions are
discussed and the performance of the controller is demonstrated using data collected
during testing.
In the fifth chapter, conclusions are drawn based on simulated and experimental field
tested data. Possible future work to improve the system is also discussed.

19. 11
2.0 SYSTEM DESCRIPTION
Figure 2.1 shows the architecture of the Triton Control system used for this project. To
perform coordinated control, the operations/control computer interfaces with the Triton
ROV, with a commercial acoustic tracking system, and with a robotic kayak.
Triton is plugged into a commercial analog control console. This control console is
connected to a digital interface called the Low Voltage Enclosure (LVE) [19]. This was
built by SCU students for a previous implementation of depth and heading lock [6]. The
kayak supports surface operations in support of ROV tasks. It is remotely controlled by
the control computer through a wireless communication link. An acoustic beacon on
Triton signals its position to an Ultra Short Baseline (USBL) transducer hung from the
ship. This plugs into the acoustic tracking computer which geolocates the ROV with the
aid of a GPS receiver. The ROV position data is then sent to the control computer.
Figure2.1: System level overview of Triton during operation with Kayak tracking

20. 12
2.1 Triton
The Triton ROV [6] has 2 horizontal thrusters and 2 vertrans thruster. The horizontal
thrusters provide movement in two degrees of freedom – yaw and forward/backward and
the vertrans thrusters provide movement in two degrees of freedom – vertical and crab
left/right.
Figure 2.2: Triton ROV makes use of 4 thrusters for propulsion. A - 0.5HP
thrusters for forward/backward movement with desired Yaw.B - 0.25HP vertrans
thrusters for vertical and side-way movement. C - Beacon that communicates to
the Transducer at the base ship.D – Tether E- Camera F - Lights

21. 13
Figure 2.3: Triton ROV system level diagram.
The vertrans thrusters are angled at 40 degrees which allows vertical and translational
movement of the ROV. The ROV is hydrostatically stable such that user control of pitch
and roll are not required. The auxiliary components such as lights and camera are used to
relay video feedback to the base station. The ROV control console throttles thruster
power down the tether based on joystick commands, and analog signals representing
depth and heading are sent up the tether. Figure 2.3 shows a system level diagram of
Triton. The acoustic tracking Beacon sits in the front of the ROV as shown in Figure 2.2
providing an unobstructed view for effective underwater acoustic communication.
2.2 Robotic Kayak
The robotic kayak shown in Figure 2.3 is a part of a fleet that was already designed for
multi-robot cluster control research [7].
Figure 2.4 shows a system level diagram of the kayak. It makes use of two Minn Kota
Endura 30 thrusters, configured on each side for differential drive. The motor controller
is a Roboteq AX1500 interfaced via an RS 232 connection.

22. 14
Figure2.3: Robotic Kayak used to track ROV
A standard marine deep-cycle battery is centrally mounted. It has a top speed of 5 knots.
Two Metricom Ricochet modems facilitate communication to the kayak, receiving motor
commands and sending back position data from an on-board GPS receiver and compass
Figure 2.4: Robotic Kayak system level diagram.

23. 15
2.3 Acoustic Tracking System
The Applied Acoustics EasyTrak system [10] is a USBL acoustic tracking system which
uses an ROV- mounted beacon and a ship mounted transducer in order to compute the
ROV’s relative position to the boat. The transceiver head normally contains three or more
transducers separated by a baseline of 10 cm or less.
The basic components of the acoustic tracker are shown in Figure 2.6. The transceiver is
shown in Figure 2.6(a), and a beacon unit is shown in Figure 2.6(c). Figure 2.6(b) shows
the signal processing unit which processes all the acoustic signals, computes the ROV’s
location and sends it to the computer.
Figure 2.5: Acoustic Transducer below base station with Triton in the background

24. 16
Figure 2.6:(a) Acoustic Transducer (b) Signal processing unit (c) beacon
Figure 2.7: Acoustic tracker system level diagram and hardware setup

25. 17
Figure 2.7 shows the system level diagram of the Acoustic tracker. The splitter box
duplicates the data for use on the Acoustic tracking computer and the Controller
computer.
By making calculations based on the time taken for the signal to travel through the water
as well as more precise phase calculations within the transponder itself, the bearing and
range of Triton can be determined. For the range of possible missions for Triton and with
its intrinsic limits such as a maximum diving range of 1000 feet, the USBL system
provides enough accuracy for refined control on all of the ROV’s deployments.
The signal processing unit sends digital (x, y, z) coordinate data to the control computer
as well as to a computer dedicated to the tracking system. The control computer uses the
data to execute the control algorithm. The Applied Acoustics software shown in Figure
2.8 runs on the Acoustic tracking computer and shows a real-time display of the ROV’s
location. The acoustic tracking software provides the user with a UI to see the relative
position of the ROV with respect to the boat. The communication between the transudcer
and the beacon can be enabled/disabled using the UI. Among many features, the
smoothing and averaging functions are available to be modified. The setup requires the
tracking software to be running in order to import the duplicate data into Matlab. The
software allows a GPS receiver to be hooked to the system and calculates the location of
the ROV in GPS coordinates by using the GPS coordinates of the boat and the relative X,
Y position of the ROV with respect to the boat. These functionalities of the acoustic
tracker work straight out of the box, but considerable time went into understanding the
system better to improve the performance of the system.
The performance of acoustic data changes depending on various conditions such as
external noise, reflections, echoes and other factors. In order to get the best out of the
system it was important to minimize the effect of disturbances on the system. By
changing various parameters such as the intensity of ping, the frequency of ping and to
make use of the built in smoothing, averaging and other features available in the

26. 18
software, this can be achieved to some extent. A lot of time and effort was spent in
adjusting various parameters to get the best possible setup.
Figure2.8: Easytrak Acoustic tracking Software User Interface
The performance of the acoustic tracker was initially studied in a closed test tank at the
Monterey Bay Aquarium Research Institute. Since this was a closed environment, it was
ideal to change the various parameters and test the performance of the acoustic tracker.
Many hours were spent at the test tank adjusting various parameters and studying the
performance of the acoustic tracker. Unfortunately, the errors varied greatly across the
test tank due to reflections of the acoustic signals off the walls of the small tank.
Although the test tank was a great environment testing, the unreliable data at different
locations of the test tank meant that the control system could not run effectively, hence
most of the control system testing was done in real world environments.

27. 19
2.3.1 Filtering Approach
To improve positioning, the raw data from the acoustic tracking is filtered.
First, a simple outlier detection and elimination function is used:
− < (1)
where is the previous value, is the present value, and ’d’ is the maximum
distance that can be travelled by the ROV in the sampled time. If the difference is greater
than ‘d’, the present value is eliminated and the next value is taken as the new value.
A simplified Kaman filter is then used to smooth sensor input. The Kalman filter [18] is a
statistical method with a set of mathematical equations that provides an efficient
computational (recursive) means to estimate the state of a controller. The Kalman
filtering algorithm is carried out in the steps mentioned below. Equation (2) and (3) are
the state propagation equation and measurement equation respectively where ( ) is the
state vector, ( ) is the input vector, ( ) is the process noise:
( + 1) = ( ) + ( ) + ( ) (2)
( ) = ( ) + ( ) (3)
( ) represents the measurement vector which is composed of measurement output of all
sensors in the system. This measurement vector is a function of state vectors and the
relationship is established through the matrix . ( ) is the measurement noise or sensor
noise.
For the prediction step the future values of the states vector in the system are calculated
as a function of the current state values and the input vector at the current time stamp. In
the Prediction step we have not taken account of the sensor measurement.
( + 1| ) = ( | ) + ( ) (4)

28. 20
( + 1| ) = ( | ) + (5)
where F is the state transition matrix, G is the control input matrix, is the process error
covariance matrix. The entries in F and G matrices are specific to the nature of the model.
For more information refer to the Kalman filter article [18].
In the simplified version of the filter used for this research project, the assumption was
made that u(k) = 0 for all motion. Given the slow commanded motion of the ROV, this
assumption resulted in acceptable performance.
In the correction step the error between predicted state values and the actual state values
derived from sensor measurement in equations (6), (7) and (8) is computed. This error
value is called ‘Innovation’. is the measurement error covariance matrix.
= ( + 1| ) + (6)
= ( + 1| ) (7)
Innovation variable is given by
y = Z(k + 1|k)−Hx′
(k + 1|k) (8)
In the ‘Innovation’ step information about the state value which is not captured by the
prediction step through the Kalman gain matrix ( ). We determine the weightage of
incorporating ‘Innovation’ values to the Prediction step in order to obtain the best
estimate. This is carried out in equations (9) and (10).
( + 1| + 1) = ( + 1| ) + (9)
( + 1| + 1) = ( − ) ( + 1| ) (10)

29. 21
For the control system, the following values were used:
G = 0.5 (time step)
F =
1 0 0
0 1 0
0 0 1
Q =
0.04 0 0
0 0.04 0
0 0 0.04
R =
100 0 0
0 100 0
0 0 100
H =
1 0 0
0 1 0
0 0 1
2.3.2 Filtering Results
Figure 2.9 is an example of an initial test that was done at Stevens Creek Reservoir to
characterize static data. Position readings are in meters with respect to the transducer at
the base station (boat). The cluster of dots at one spot is the actual reading of the beacon.
The rest of the values scattered all around are outliers that are caused due to echoes and
other disturbances. This noise was mitigated by modifying the transducer ping rate and
incorporating the filtering approach described in the previous section. Figure 2.10 shows
the filtered data in green and raw data in blue in the X axis and Figure 2.11 shows the
filtered data in green and raw data in blue in the Y axis. The performance improved after
the filter was added.

30. 22
Figure 2.9: Raw Performance of Acoustic tracker with many outliers
Figure 2.10: Filtered X axis performance of acoustic tracker.

31. 23
Figure 2.11: Filtered Y axis performance of acoustic tracker.
Figure 2.12: Filtered Performance of Acoustic tracker

32. 24
Figure 2.12 shows the performance of the filtered values in the X-Y axis.
The RMS errors after filtering were 2.9237m in X and 3.6255m in Y. The real location
was (0.8,-0.9) subject to a combined acoustic tracking and GPS error.
2.4 Software Architecture and Communication
Figure2.13: System Communication
Figure 2.13 shows the software architecture on the control computer. This architecture
uses the DataTurbine [9] data streaming server to exchange information between different
software applications. For this system, these applications include Matlab as well as
simple interface programs to send/receive information through hardware parts (such as
serial and USB connections) to/from other devices. These devices include the Triton
LVE, the wireless communication radio for the kayak, and the Easytrak signal processor.

33. 25
3.0 CONTROL SYSTEM
The position state of the Triton ROV/kayak system is controlled by the control modes
illustrated in Figure 3.1. The overall objective of the project was to use feedback control
for improved performance and operability of ROV operations.
Figure 3.1: Triton system control modes.

34. 26
This has been done by implementing several pilot aid functions and also an autonomous
navigation function for the ROV. In addition, the coordinated control of the kayak surface
vessel assists with identifying the position of the ROV and/or specifying the desired
navigation points.
Figure 3.2 shows the ROV and kayak with their local frames defined in the global frame.
Figure 3.2: ROV and Kayak frames.
3.1 ROV Manual Control
Manual control is achieved using a joystick with which the 4 degrees of freedom Yaw,
Crab, Up/Down and Forward/Reverse can be controlled. Figure 3.3 shows the control
system architecture used for this mode. The Inverse Kinematics block has Velocity as
input from the joystick and outputs PWM signals to the LVE. Crab (X’), Forward (Y’),
Vertical (Z’) and ROV heading ( ) can be controlled using the joystick.

35. 27
Figure 3.3: Manual mode
The equations (12), (13), (14), (15) below define the Inverse Kinematic transformation
that converts the X’, Y’, Z’ and ′ values to individual thruster PWMs.
− ′ = _ (13)
− − ′ = _ (14)
′ ∗ ( )
+ ′ = _ (15)
′ ∗ ( )
− ′ = _ (16)
3.2 ROV Pilot Aid Modes
ROV pilot aid modes include the Assisted modes which consist of Heading Lock, Depth
Lock and Path Lock. The Heading lock and Depth lock modes lock in the Heading and
Depth of the ROV respectively. These modes may be activated simultaneously or
individually.
Locking the Heading of the ROV does not prevent the ROV from drifts. Underwater
currents or disturbances in the control system may cause the ROV to drift. In the Path

36. 28
Lock mode, the controller corrects heading and bring the ROV back to the fixed path if
the ROV drifts. The path can be specified by defining two ordered path points or by a
path point and a bearing. These points can be specified by the pilot or latched with the
position values of the kayak. The Path Lock and Depth Lock features may be used
simultaneously.
3.2.1 Heading lock
Figure 3.4 shows the control system architecture used for this mode. X’, Y’, Z’ are
controlled by the joystick. Heading is automatically controlled as indicated by Equation
17. Figure 3.5 shows the desired heading and current heading in the global frame. As
before, the output of the Inverse Kinematic block feeds in the PWM thruster values to the
LVE.
Figure 3.4: Assisted: Heading
= ( − ) (17)

37. 29
Figure 3.5: Desired heading and current heading in global coordinates
Figure 3.6 shows the simulated performance of the heading lock control. This simulation
was used to verify the form of the proposed controller prior to hardware implementation.
Tuning of the controller was performed experimentally.
Figure 3.6: Heading lock simulation performance

38. 30
3.2.2 Depth Lock
Figure 3.7 shows the control system architecture used for this mode. X’, Y’, can be
controlled by the joystick and depth (Z’) can be locked using the depth velocity input to
the Inverse Kinematic block. The output of the Inverse Kinematic block feeds in the
PWM thruster values to the LVE. Equation (18) defines the process.
Figure 3.7: Assisted Depth
= ( − ) (18)
Figure 3.8 shows the desired depth and the current depth in the global coordinates. Figure
3.9 shows the performance of the simulated performance of depth lock.

39. 31
Figure 3.8: Desired depth versus measured depth in global coordinates
This simulation was used to verify the form of the proposed controller prior to hardware
implementation. Tuning of the controller was performed experimentally.
Figure 3.9: Simulated performance of depth lock control

40. 32
3.2.3 Path Lock
Figure 3.10 shows the control system architecture used by this mode. The path is defined
by two ordered planar path points (with the bearing pointing from the first to the second
point or by a single point and a bearing). These path properties may be input by the pilot
or latched into the controller based on the position of the kayak. In this mode, if the ROV
drifts outside the path, it corrects heading to fix the error. Depth is controlled by pilot
joystick input.
Figure 3.10: Assisted Path lock mode
Figure 3.11 shows the control strategy used for Path lock control mode. ROV heading
correction (Ψ) proportional to the cross track error ( ) helps the ROV return to the path
with original bearing (Φ).
= ( − ) (19)
= Φ − min (Ψ, 90) (20)

41. 33
Figure 3.11: Cross track control strategy [8]
The perpendicular distance between the current moving position of the ROV and the line
to calculate cross track error is given by:
=
| |
√( )
(21)
where is the cross track error, and are the current moving position of the
ROV, a = , b = -1 and c = − * +
Ψ = ∗ (22)
where Ψ is the corrective turn angle.
Φ = tan (23)
where Φ is the path bearing, ( , ) and ( , ) are the two points that define the path.
Figure 3.12 shows the performance of the Path lock control in simulation. The plot area
from 0 to 6 seconds was self induced error. The plot area from 6 seconds to 23 seconds
shows the path controller bringing the cross track error from 9.3 meters to 0 meters. This

42. 34
simulation was used to verify the form of the proposed controller prior to hardware
implementation. Tuning of the controller was performed experimentally.
Figure 3.12: Simulated performance of path lock control
3.3 ROV Autonomous Navigation
The control system features a fully autonomous mode wherein the ROV drives itself to a
desired location defined in X, Y, Z coordinates. The desired (X, Y, Z) destination can be
specified by the pilot. Alternatively, the (X,Y) location can be specified as the kayak
location, with the value latched to establish a specific set point or streamed in order to
slave the ROV’s planar location to the kayak. In these cases, depth can be specified by
the pilot as a set point or via the joystick.
Figure 3.14 shows the point to point controller mode. Using this mode the ROV will get

43. 35
to a specified location by entering the desired X, Y, Z coordinates. The acoustic tracker
gives the current X and Y position of the ROV with Z being provided by the LVE.
Desired heading is calculated using the equation
= tan( , ) (24)
Where = − and = - .
Velocity equations are defined as follows:
= ∗ ( − ) (25)
= ∗ ( − ) (26)
= ∗ ( − ) (27)
= ∗ ( − ) (28)
Figure 3.14: Point to point navigation
For long distances of point to point travel, the forward velocity ( ) will need to be
saturated.

44. 36
The acoustic tracker and desired X, Y, Z values are in global coordinates. Therefore, the
global to local transformation converts it to robot coordinates and the inverse kinematics
can be calculated. Figure 3.15 shows the desired (X,Y,Z) coordinates and the current
(X,Y,Z) coordinates in the global frame.
Figure 3.15: Desired point versus measured point in global coordinates
A variant of this mode is the Point to point mode using the end point as the kayak
position. The desired X, Y, Z values feeds the current position of the Kayak resulting in
the ROV driving itself to the kayak. This mode can be used in two ways – the ROV slave
switch maybe turned to the ON position after the Kayak is at the desired destination. The
ROV slave switch may also be kept ON so that the ROV tracks the kayak continuously.
Figure 3.16 shows the performance of the Autonomous control in simulation. This
simulation was used to verify the form of the proposed controller prior to hardware
implementation. Tuning of the controller was performed experimentally.

45. 37
Figure 3.16: Simulated performance of path lock control
3.4 Kayak Control mode
Manual mode is used to establish new points for the ROV for enhanced operability.
Autonomous mode is used to allow slaving the kayak to the ROV’s position for safety
and visualization purposes. Figure 3.17 shows the point to point controller mode. The
kayak is used to track the ROV and in most modes the Kayak uses the ROV location as
the desired location. Desired heading is calculated using the equation
= tan(( − ), ( − )) (26)
Velocity equations are defined as follows:
= ∗ ( − ) (27)
= ∗ ( − ) (28)

46. 38
Figure 3.17 Point to point navigation
Figure 3.18 shows the desired (X, Y) coordinates and the actual (X, Y) in the global
coordinates.
Figure 3.18: Desired point versus measured point in global coordinates

47. 39
4.0 Field Testing Data
The controller testing was done at the MBARI docks. The transducer was positioned as
far away as possible from the dock by hanging it from an anchored kayak. This was done
to limit any reflections. The confined workspace and shallow waters made it difficult to
get good position data. Improving the controller in a larger workspace will be a part of
future work.
4.1 Heading lock
Figure 4.1 shows the response to the stationary yaw input of 180 degrees from an initial
yaw of 138 degrees. The ROV overshoots by roughly 3 degrees and settling time is about
25 seconds. As seen in the figure, heading initially settles at approximately 155 degrees,
at which point the torque from the ROV tether created an unmodeled spring-like force
that induced an offset for the ROV’s proportional heading strategy. The integral control
term took over at that point, eventually nulling the steady state error.
Figure 4.1: Heading lock

48. 40
4.2 Depth lock
The pressure gauge from the ROV was used for the depth lock mode. The ROV depth
from the pressure gauge showed oscillations of about 5-7 feet and with the limited depth
at the testing facility, it took a few attempts to prove the performance of the depth lock
mode. Figure 4.2 shows the system’s response to a step command specifying a depth of 8
feet. The system settled after about 10 seconds.
Figure 4.2: Depth lock
4.3 Point to Point ROV controller
The point to point mode was tested by making use of the X and Y values from the
acoustic tracker and depth from the ROV pressure sensor. Due to noise from the pressure
sensor, the ROV surfaced a few times, resulting in loss of acoustic tracking data. For the
experiment shown in Figure 4.3-4.5 the start point of the ROV was at (X, Y) = (4,-10.5)
and the desired location was (X, Y) = (0, 0).

49. 41
Figure 4.3: Point to point mode – X vs. Time
Figure 4.4: Point to point mode – Y vs. Time

50. 42
Figure 4.5: Point to point mode – XY plot
4.4 Path lock
The cross track controller was the hardest to test given the limitations of space, noisy
depth sensor and shallow waters. A path was set with a bearing of 45 degrees. It can be
seen from Figure 4.6 - 4.7 that the path lock controller reduces the cross track error and
brings the ROV closer to the desired path. More exhaustive testing and tuning of the
controller was not possible due to the depth limitation of the test area; the ROV needed to
be submerged by 8 feet for the acoustic tracker to work well. The total depth in the area
was about 12-15 feet.
Improving the performance of the controller by tuning it in a better testing environment is
a part of future work.

51. 43
Figure 4.6: Cross track controller: Ect vs. Time
Figure 4.7: Cross track controller: X, Y plot of desired path vs. actual path

52. 44
4.5 Point to Point Kayak controller
For this mode, GPS from the Kayak was used for position sensing. The desired location
was set to (X, Y) = (0, 0) and the start point was (X, Y) = (35, 17.5). The performance of
the controller is shown in Figure 4.8 – 4.10. The system settled after about 23 seconds.
Figure 4.8: Kayak point to point controller - X vs Time
Figure 4.9: Kayak point to point controller - Y vs Time

53. 45
Figure 4.10: Kayak point to point controller - XY plot
4.6 Point to Point: Kayak tracking ROV
The Kayak was slaved to the ROV and the ROV was piloted using a joystick. The
performance of the controller is shown in Figure 4.11 – 4.13.
The RMS error in X axis was about 3.67m and the RMS error in the Y axis was 4.91m.
The error was close to 0 at the end of the run.

54. 46
Figure 4.11: Kayak tracking ROV - X vs. Time
Figure 4.12: Kayak tracking ROV - Y vs. Time

55. 47
Figure 4.13: Error plot for distance between ROV and Kayak
4.7 Summary
The experiments were completed successfully and the controller performed to
expectations.
The heading lock mode controlled heading to within 3 degrees of the commanded set
point and took about 25 seconds to settle down; mainly because of the spring like tether
disturbances which required the integral control term to take over. The depth lock had an
error range of about 5-7 feet. Since the testing environment was only about 15 feet in
depth, it was difficult to show the performance of the depth lock. The system took about
10 seconds to settle down.
The point to point ROV control mode worked well with the ROV reaching the desired
destination to within 2 meters in about 14 seconds. The ROV re-surfaced a few times

56. 48
because of the noisy depth sensor; this degraded performance since the ROV needed to
be submerged by about 8 feet in order for the acoustic tracking system to properly sense
its depth. This issue continued to be a problem during all experiments that required the
ROV to be submerged for X, Y position control. The path lock mode was the hardest to
test because of the limitations of space, noisy depth sensor and limited visibility. This
mode worked successfully but required several attempts. It requires further tuning and
improvement and is a part of future work.
The point to point kayak controller worked well and the kayak reached its desired
destination to within 1 meter in 23 seconds. The kayak tracking ROV mode also worked
well and the RMS error between the ROV and the kayak was close to the specified RMS
error of the acoustic tracker itself. Because of the issues with the workspace, the ROV
tracking kayak control mode was not experimentally verified.
Although experimental results were limited, testing showed that all but one of the modes
functioned. Additional tuning in open water will be required to obtain optimal
performance.

57. 49
5.0 Conclusion
5.1 Summary and Conclusion
The motivation of this thesis was to improve the efficiency of Triton ROV operations.
The controller enables more explorations in a by enhancing the effectiveness of the pilot
with the assisted and automated control modes. In order to implement this system, a
computer control interface was developed that integrated the ROV, a surface vessel (a
Robotic Kayak) and an external acoustic tracking system. This resulting control system
implemented several control modes such as depth and heading lock, 3- dimensional
waypoint control, and 2 dimensional path following control. Coordinated ROV/Kayak
control modes were also implemented such as using the kayak to specify the (X, Y)
position of navigation points, slaving the kayak’s position to be above the ROV and
slaving the ROV to be under the kayak.
The control modes were verified in both simulations and in actual experiments.
The field experiments were successful in demonstrating the performance of the
controller. The heading lock took about 25 seconds to settle to within 3 degrees of the
commanded set point. The Depth lock was limited by the noisy pressure sensor and the
shallow waters but performance was acceptable with the vehicle taking about 10 seconds
to settle to within 6 feet of the commanded depth. The ROV tracking mode worked well
but was again limited by the noisy depth sensor and the shallow waters. The ROV
reached the desired destination to within 2 meters in about 14 seconds. The path lock
mode was the hardest to test. The experimental results demonstrated the functionality of
this control mode but there was an error of about 10 meters at the end of the run. The
kayak tracking ROV mode worked well and the RMS error between the ROV and the
kayak was within the range of the RMS error of the Acoustic tracker. The kayak tracking
mode worked very well and took about 23 seconds to reach its desired destination with an
error less than 1 meter at the end of the run.

58. 50
This thesis demonstrated the ability of the controller to aid in efficient field operations. It
also sets the benchmark for the development of a collaborated controller combining
vehicles from different domains.
5.2 Future Work
There are many areas in which this research can be improved and taken further. Firstly,
open water tests have to be conducted in order to test all the modes and tune the system.
Although not a limitation of the system itself, one of the challenges faced while testing
the system was the inability to test the controller in a pool (a controlled environment).
This meant that we had to step into the field each time the controller had to be tested. The
reflections from the walls of the pool resulted in an extremely noisy acoustic tracking
environment. Having a controlled environment by limiting acoustic tracking noise would
help improve the system by a great margin since it would help a researcher to test and
tune the system and not have to face the limitations in the field such as working on a boat
with generators, limited space, limited visibility, drifting GPS location etc. Another
system worth exploring would be an improved sensing architecture such as an acoustic
tracking system with an Inertial Measurement Unit to improve sensor data. A simplified
version of the Kalman filter was used to improve the acoustic tracking data. A full
version of the extended Kalman filter will further improve the performance of acoustic
tracking data and is a part of future work.
One of the learning experiences in the field was that for every control mode, a new set of
control gains were required. Redesigning the system to account for new gains based on
the mode would improve the performance of the system overall. Furthermore, creating an
easy to understand GUI where different modes can be switched on or off with easy
viewing of interested parameters such as input value, measured value, error etc. and with
tunable gains will help efficient operability of the controller.
Multi-vehicle control is also an interesting area of future work. Using multi-kayaks for
dive area protection by combining the existing controller with the previously

59. 51
implemented dynamic guarding strategy [7] or the patrolling strategy [21] are research
areas worth exploring. Coordinated Multi- ROVs for benthic surveys, or coordinated
camera and lights on different ROVs [22] guided by the Kayak may also be of significant
research interest.

60. 52
References
[1] National Oceanic and Atmospheric Administration “William Beebe sitting on
Bathysphere” Internet:
http://oceanexplorer.noaa.gov/explorations/05stepstones/logs/aug15/media/beebe_on_bat
hysphere.html, August 26, 2010 [Sept. 6 2013]
[2] Alex Czartoryski “The History of Deep Sea Exploration” Internet:
http://www.boaterexam.com/blog/2011/06/history-of-deep-sea-exploration.aspx, 3 June
2011 [Sept. 6, 2013]
[3] Natural History Museum “The History of Ocean Exploration” Internet:
http://www.nhm.ac.uk/nature-online/science-of-natural-history/expeditions-
collecting/hms-challenger-expedition/exploration-history/index.html, [Sept. 6 2013]
[4] National Oceanic and Atmospheric Administration “NOAA’s New Ship Targets Path
– Finding Ocean Exploration and Research” Internet:
http://www.noaanews.noaa.gov/stories2005/s2370.htm, 18 Jan 2005 [Sept. 6 2013]
[3] NBC “Oil from massive Gulf spill reaching La. coast” Internet:
http://www.nbcnews.com/id/36800673/ns/us_news-environment#.UbcNEfmcdbo.htm, 30
April 2010 [Sept. 6 2013]
[5] Monterrey Bay Aquarium and Research Institute “ROV Ventana” Internet:
http://www.mbari.org/dmo/vessels_vehicles/ventana/ventana.html, 07 Mar 2013 [Sept 6
2013]
[6] Jeffrey Abercrombie, Kevin Brashem, Johnny Buccola, Matt Pavlik "Triton
Autonomous Navigation and Integrated Control" Bachelor’s Thesis, Dept. of Mechanical
Engineering, Santa Clara University, Santa Clara, CA, July 2010.

61. 53
[7] Paul Mahacek, Christopher A Kitts, Ignacio Mass "Dynamic Guarding of Marine
Assets through Cluster Control of Automated Vessel Fleets" IEEE/ASME Transactions on
Mechatronics, vol 17, no.1, pp 65-75, April 2011.
[8] Christopher Kitts, Paul Mahacek, Thomas Adamek, Ketan Rasal, Vincent Howard,
Steve Li, Alexi Badaoui "Field Operation of a Robotic SWATH Boat for Shallow-Water
Bathymetric Characterization" Journal of Field Robotics, Vol. 29, Issue 6, pages 924–
938,November/December 2012.
[9] Paul Hubbard “Dataturbine for Science” DataTurbine presentation at PASI Costa
Rica. Internet: http://www.dataturbine.org/content/dataturbine-presentation-pasi-costa-
rica-0 June 4 2008 [Sept. 6 2013]
[10]Applied Acoustics Underwater Technology, Internet:
http://www.appliedacoustics.com/easytrak-usbl-systems [Sept. 6 2013]
[11] Triton Submarines LLC, Internet: http://tritonsubs.com/submersibles/triton-360003
[Sept. 6 2013]
[12] Triton-36000, Internet: http://tritonsubs.com/wp-content/uploads/2012/03/Triton-
36000-3-Brochure-1.1.pdf , [Sept. 6 2013]
[13] Ker Than, Photography Mark Thiessen “James Cameron Headed to Ocean's Deepest
Point Within Weeks” Internet:
http://news.nationalgeographic.com/news/2012/03/120308-james-cameron-deepest-
mariana-trench-challenger-science-sub, 8 March 2012 [Sept. 6 2013]
[14] Steve Haddock, Magdalena Halt, Russ Hopcroft, George Matsumoto, Karen Osborn,
Kevin Raskoff, Kim Reisenbichler, Bruce Robison, Rob Sherlock, Jessica Silguero, Sarah
Skikne, and Mario Tamburri (Monterrey Bay Aquarium Research Institute) “Discoveries

62. 54
of deep-sea biomass and biodiversity using an ROV” Internet:
http://www.mbari.org/twenty/biodiversity.htm Aug 2007 [Sept 6. 2013]
[15] Mark Spear (Photography) “Major Upgrade Scheduled for Alvin, the U.S.'s Deepest
Diving Research Sub” Internet: http://www.whoi.edu/page.do?pid=50915, Dec 2010
[Sept. 6 2013]
[16] Wikipedia “Bathyscape Trieste” Internet:
http://en.wikipedia.org/wiki/Bathyscaphe_Trieste, 30 July 2010 [Sept 6 2013]
[17] Woods Hole Oceanographic Institution “HOV Deep Sea Challenger” Internet:
http://www.whoi.edu/main/deepseachallenger , March 26 2013 [Sept 6 2013]
[18] Einicke, G.A., White, L.B. “Robust Extended Kalman Filtering” IEEE Transactions
on Signal Processing, Vol 47, Issue 9, pp. 2596-2599, September 99.
[19] Oli Francis, Graeme Coakley, Christopher Kitts “A Digital Control System for the
Triton Undersea Robot” Ifac Conference On Mechatronic Systems; Vol. 2; pp. 633-638,
2002.
[20] Eric Beidel “At the Coast Guard’s Expo, the Biggest Star Is the Robot That Plugged
the BP Leak” Internet:
http://www.nationaldefensemagazine.org/blog/lists/posts/post.aspx?ID=241, Nov. 10
2010 [Sept. 6 2013]
[21] I. Mas, S. Li, J. Acain, and C. Kitts, “Entrapment/escorting and patrolling missions
in Multi-robot cluster space control”, IROS'09 Proceedings of the 2009 IEEE/RSJ
international conference on Intelligent robots and systems, pp.5855-5861, October 2009

63. 55
[22] Michael Alan Neumann, “Design and Simulation of Single-Pilot Control for Two
Holonomic Vehicles of Heterogeneous Functionality” M.S. thesis, Dept. Mech. Eng., Santa
Clara Univ., Santa Clara, CA, Aug. 2008.

64. 56
Appendix A
Procedure to run Controller
1.0 Objective: The objective of this document is to run the general software setup
required to start the controller and to run through the different modes available in the
controller.
2.0 Connections and Setup:
Ensure the following USB connections are plugged in to the controller laptop:
1.) USB from LVE.
This is the USB line to send control commands to Triton and to receive heading
and depth data from Triton.
2.) USB from acoustic tracker.
The Acoustic tracking (AT) laptop is assumed to be running at this point. The
primary AT USB is plugged in to the AT computer. The secondary USB goes to
the controller laptop.
3.) USB from modem. (Required if you want to run the kayaks)
The modem that communicates with the Kayak is also plugged in to the controller
computer.
4.) Joystick USB.
Communications
In order to initiate communications with the LVE:
1.) Start Dataturbine.
2.) Start an instance of Remote Node Server and do the following:
-Choose COM port that the LVE is connected to.

65. 57
-Use default settings for baud rate and flow control (Respond with ‘y’).
-Do not use the default 2 way communication (Respond with ‘n’).
-‘localhost:3333’ for Dataturbine host.
-‘TNode’ for node name.
-‘TData’ for telemetry channel name.
- Add a command channel (Respond with ‘y’).
-‘*/Tcommand’ for command channel name.
The screenshot of the Remote Node server is as shown below. You will see data
streaming in to the Remote Node server after you enter the command channel
name (Not shown here).
Figure 1: LVE Remote Node Server setup
3.) In the Matlab window run the Triton_Init.m file.
4.) You will see heading and depth data in the Workspace window of Matlab.
In order to initiate communications with the AT:
1.) Start another instance of Remote Node server and do the following;
Use default settings for baud rate and flow control (Respond with ‘y’).

66. 58
Use default connection (Respond with ‘y’)
Screenshot as shown below. You will see data streaming in to the Remote Node
server at this point (Not shown in the picture).
Figure 2: AT Remote Node Server setup
2.) Run the Acoustic_Init.m file. (At this point you may see a few errors but don’t
worry about it. It will be fixed after the next step is complete)
3.) Run the ZeroGPS_ROV to see ‘X_E’ and ‘Y_N’ data in the Workspace. You will
also see some other state variables in the workspace which is used by the Zero
GPS function.
In order to initiate communications with Modem (Kayak):
1.) Run the first ‘robot modem’ batch file.
The COM port of the modem connected is in this batch file. Ensure the COM port
matches the modem connected.
2.) Run the ‘start’ modem batch file.

67. 59
The name of the Kayak (modem name in the kayak) is mentioned. Change the
name if it does not match the kayak modem name.
3.) Run the BoatDTconnection command in the command window of Matlab
‘robot = BoatDTconnection(robotname, ipAddress, tcpPort, motorConstant)’
4.) Run the “calibrate_robot.m” file to zero the GPS.
All data and communications streams are ready for the Matlab controller to run at this
point.

68. 60
3.0 Controller
“TRITON_CONTROLLER_ONLY_ROV.mdl” file is the main Sim file. (The “ONLY
ROV” part of the name may be misleading, I had that name for debugging purposes and
never changed it) Figure 3 below shows the pilot GUI to operate the controller. Make
sure ‘Auto’, ‘Heading lock’, ‘Depth lock’, ‘path lock’, ‘Use kayak for heading’ switches
are in the OFF position.
There are times when you don’t want to use the Kayak system for debugging purposes or
otherwise. During such instances, you can disable the kayak system by replacing the
“GPS data” matlab function with a dummy constant block and by removing the Modem
command block. This is located inside the “Kayak subsystem” block. This way, all the
controller functions of the ROV that does not require the Kayak system can still be used.
Manual
When you run the Matlab controller, you should be able to joystick the ROV OR the
Kayak at any point. The joystick switch toggles between the ROV and the kayak.
Heading Lock
The “Heading lock” switch locks the heading of the ROV (Figure 4). You may switch
between entering a desired heading value or locking the heading based on the current
compass reading by using the “Direct yaw val” switch.
Figure 4: Heading lock and Direct Yaw val switches.
You may also use the Kayak to define heading (ROV heading towards kayak). The
controller makes use of the current ROV location and the Kayak location to define the
desired heading. This can be used by switching on the “Use kayak for heading” switch.
This function only works when the “Heading lock” switch (heading lock) is turned on.

69. 61

70. 62
Figure 5: Using Kayak for heading
Depth Lock
The “depth lock” switch (Figure 6) locks the depth of the ROV. You may switch between
entering desired depth value or locking the depth based on the current pressure sensor
reading by using the “Direct depth val” switch.
Figure 6: Depth lock and direct depth val switches
Path Lock
Path lock accounts for any crosstrack drift and compensates heading to bring the ROV
back to its path. This can be switched on by using the “Path lock” switch. This mode can
only be used when the heading is locked (Figure 7).
Autonomous Control
Figure 7: Path lock
The autonomous controller can be used to slave the ROV to the kayak (ROV tracks kayak
and Kayak can be controlled using joystick) or slave the Kayak to the ROV (Kayak tracks
ROV and ROV can be controlled using joystick or can be run in any of the assisted or

71. 63
automated control modes.). This mode can be switched on by using “Auto On/OFF”
switch and the “RoV slave/kayak slave” switch can be used to toggle between the ROV
following kayak mode or Kayak following ROV mode (Figure 8).
If you would like to run the ROV without the kayak, disconnect the Kayak GPS
measured values feeding into the Automatic controller and replace with the desired
constant (X, Y, Z) values. This can be changed in the “Automatic controller” block inside
the “ROV Susbsytem” block (Figure 9).
Figure 8: Autonomous control
Figure 9: Switching kayak measured values with desired values

72. 64
Appendix B
Controller code
Triton_Init.m
%Triton Init function to initialize communications with Dataturbine
%Arjun Menon
%RSL 2013
Tmcontroller = controller('localhost','3333','TMatlabController');
registerfunction(Tmcontroller,'TritonData','*/TData');
addcommandchannel(Tmcontroller,'Tcommand');
start(Tmcontroller)
oldtime=clock;% get the current time for the DataTurbine write loop
newtime=clock;
Acoustic_Init.m
%Acoustic Initialize file to initiate communication with dataturbine
%Arjun Menon
%RSL 2013
mcontroller = controller('localhost','3333','MatlabController');
registerfunction(mcontroller,'trackerdatahandling','*/data');
addcommandchannel(mcontroller,'command');
start(mcontroller)
Kalman Filter code:
% Sreekanth Dayanidhi & Arjun Menon
% RSL 2013
% Function to filter noisy acoustic tracking data.
function xyfilt = Acoustic_Kalman_Real(u)
%#eml
% if (u==1)
eml.extrinsic('evalin');
eml.extrinsic('assignin');
%%
%-----------------------------------------------------------

73. 65
%-----------------------------------------------------------
% Kalman Filter Begins Here
% % Description
% Ref: http://en.wikipedia.org/wiki/Extended_Kalman_filter
%-----------------------------------------------------------
%-----------------------------------------------------------
counter = 0;
c = textread('DelValle08.03.X6.txt');
for i = 1:5000
XMeas = c(i,1);
YMeas = c(i,2);
ZMeas = 0;
% fid = fopen('MBARISvals_3.txt','at');
% fprintf(fid, '%f %f %f n n n', XMeas,YMeas,ZMeas);
% fclose(fid);
Vx = 0;
Vy = 0;
Vz = 0;
%-----------------------------------------------------------
% 1) Initializing covariance matrices
%-----------------------------------------------------------
Fmatrix = eye(3); % Identity Matrix
Qmatrix = [0.04 0 0;0 0.04 0;0 0 0.04]; % Process noise covariance.
error variance matrix for x, y, z. Model error
Rmatrix = [300 0 0;0 300 0;0 0 300]; % Measurement noise covariance
Imatrix = eye(3); % Just an Identity Matrix
time_step = 1;
%-----------------------------------------------------------
% 2) Predicted state estimate based on x(k-1) and u(k-1)
%-----------------------------------------------------------
Xposold = evalin('base', 'XWposold'); % state1: X
Yposold = evalin('base', 'YWposold'); % state2: Y
Zposold = evalin('base', 'ZWposold'); % state3: Z
dist = sqrt(Xposold^2 + Yposold^2) - sqrt(XMeas^2 + YMeas^2);
dist = abs(dist);

74. 66
if (dist <(0.5 + counter))
counter = 0;
Xposnew = Xposold + time_step*Vx ;
Yposnew = Yposold + time_step*Vy ;
Zposnew = Zposold + time_step*Vz;
PosvectorPred = [Xposnew;Yposnew;Zposnew];
%Note: Target is sationary is as of now there is no target's state
estimate.
%-----------------------------------------------------------
% 3) Predicted estimate covariance
%-----------------------------------------------------------
Poldmatrix = evalin('base','Poldmatrix');
Pnewmatrix = Fmatrix*Poldmatrix*(Fmatrix') + Qmatrix;
%-----------------------------------------------------------
% 4) Innovation or measurement residual
%-----------------------------------------------------------
Y1Inov = XMeas - Xposnew;
Y2Inov = YMeas - Yposnew;
Y3Inov = ZMeas - Zposnew;
YvectorInov = [Y1Inov;Y2Inov;Y3Inov];
%-----------------------------------------------------------
% 5) Innovation covariance
%--------------------------------------- `--------------------
Hmatrix = eye(3);
Smatrix = Hmatrix*Pnewmatrix*(Hmatrix') + Rmatrix;
%-----------------------------------------------------------
% 6) Optimal Kalman Gain
%-----------------------------------------------------------
Kmatrix = Pnewmatrix*(Hmatrix')*(inv(Smatrix));
%-----------------------------------------------------------
% 7) Update State Estimate
%-----------------------------------------------------------
PosvectorUpdate = PosvectorPred + Kmatrix*YvectorInov;
XposU = PosvectorUpdate(1);
YposU = PosvectorUpdate(2);
ZposU = PosvectorUpdate(3);

75. 67
assignin('base', 'XWposold', XposU);
assignin('base', 'YWposold', YposU);
assignin('base', 'ZWposold', ZposU);
xyfilt = [XposU YposU];
FposU = [XposU;YposU;ZposU];
fid = fopen('AelValle081013Fvals_1.txt','at');
fprintf(fid, '%f %f %f %f n n n n', XposU,YposU,c(i,3),c(i,4));
fclose(fid);
%-----------------------------------------------------------
% 8) Update estimate covariance
%-----------------------------------------------------------
PmatrixU = (Imatrix - Kmatrix*Hmatrix)*Pnewmatrix*((Imatrix -
Kmatrix*Hmatrix)')...
+ Kmatrix*Rmatrix*(Kmatrix');
assignin('base', 'Poldmatrix', PmatrixU);
%-----------------------------------------------------------
%-----------------------------------------------------------
% Kalman Filter Ends Here
%-----------------------------------------------------------
%-----------------------------------------------------------
else
counter = counter + 0.5;
fid = fopen('AelValle081013Fvals_1.txt','at');
xyfilt = [Xposold Yposold];
fprintf(fid, '%f %f %f %f n n n n', Xposold,Yposold,c(i,3),c(i,4));
fclose(fid);
end
end
end
TritonData.m
%Arjun Menon
%RSL 2013
%Call back function to handle Heading and Depth data from ROV
function TritonData(data)
bytearray = data.getArray;
% b =zeros(8,1);
% b = char(java.lang.String(bytearray));
b=(bytearray);
l = typecast( b(3),'uint8');
m = typecast( b(4),'uint8');
ff = double(l);

76. 68
gg = double(m); %It was typecasted to
'double' because Matlab cannot add uint8 values.
heading_in = ff+gg;
heading_in = double(heading_in);
d1= double(typecast( b(5),'uint8')); %It was typecasted to
'double' because Matlab cannot add uint8 values.
d2 = double(typecast( b(6),'uint8'));
d3 = double(typecast( b(7),'uint8'));
d4 = double(typecast( b(8),'uint8'));
yawin = (double(heading_in)/360)*2*pi;
depth = d1+d2+d3+d4;
%yawin = (heading_in/360)*2*pi;
assignin('base','Heading_IN',heading_in);
assignin('base','DEPTH_IN',depth);
assignin('base','YAW_IN',yawin);
%disp(heading_in);
end
Acoustic tracker.m:
function acoustictracker(dtip,dtport,functionname,channelname,appname)
% AUCOUSTICTRACKER Setup for the client-side software for the acoustic
% tracking system.
% ACOUSTICTRACKER(DTIP,DTPORT,FUNCTIONNAME,CHANNELNAME,APPNAME) is a
% utility function that establishes the connection to the DataTurbine
and
% registers the default function ('trackerdatahandling') as the
callback
% to be used for data handling. DTIP is the IP address of the
% DataTurbine. DTPORT is the specific port being used for
communication.
% FUNCTIONNAME is the name of the callback function to be called upon
the
% receipt of data and may be excluded in the case that the default
% function is to be used. CHANNELNAME is the name of the channel used
for
% providing data from the acoustic tracking system and may be
excluded if
% the default ('data') is to be used. APPNAME is an identification of
the
% client-side application serving to provide accessible information
in
% the case that another application requests the names of clients
% connected to the DataTurbine instance and can be excluded. In the
case
% that the functionname, channelname, or appname are excluded,
anything
% beyond the DataTurbine port specification will be ignored. If the
% function is called with no parameters specified it is assumed that
the
% DataTurbine IP address and port are 'localhost' and '3333'
% respectively.

77. 69
%
% In order to properly start and stop the underlying thread that
handles
% the notification of data receipt to the registered callback
funtion,
% the Java MatlabController object is put on the workspace. The
% MatlabController should be stopped and cleared from the workspace
to
% release resources.
%
% Example 1: Create a connection
%
%
acoustictracker('129.210.0.0','3333','handlerfunction','/tracker/da
% ta','trackerapp');
%
% Example 2: Create a connection using the default function, channel,
and
% application name.
%
% acoustictracker('129.210.0.0','3333');
%
% Example 3: Create a connection with the server and client running
on
% the same computer. This scenario is useful during testing.
%
% acoustictracker
%
% Author: Mike Rasay
% Version: 0.1.0
% Matlab Version: 2009a
% Created: 2010.01.19
if nargin == 0
dtip = 'localhost';
dtport = '3333';
functionname = 'trackerdatahandling';
channelname = 'RemoteNode/data';
appname = 'trackerclient';
elseif nargin >= 2 && nargin < 5
functionname = 'trackerdatahandling';
channelname = 'RemoteNode/data';
appname = 'trackerclient';
end
% create the MatlabController object
conn = controller(appname,dtip,dtport);
% register the callback function
registerfunction(conn,functionname,channelname);
% start the controller
start(conn);
% put the MatlabControler object on the workspace
%global z;
%assignin('base','trackercontroller',conn);

78. 70
%global x y z;
Add command channel.m
function channelidx = addcommandchannel(controller,channelname)
% ADDCOMMANDCHANNEL adds a command channel to the controller.
%
% CHANNELIDX = ADDCOMMANDCHANNEL(CONTROLLER,CHANNELNAME) adds a
command
% channel to the specified CONTROLLER with the specified CHANNELNAME.
The
% CHANNELIDX is the index of the added channel and should be used as a
% reference when sending data (commands) on the channel.
%
% This function is provided as a convenience function and the
% functionality can be acheived by explicitly calling the
% 'addCommandChannel' function of the controller Java object. The code
% contained in this function can be duplicated in a script, function,
or
% the command prompt with the same results as this function.
%
% Author: Mike Rasay
% Version 0.1.0
% Matlab Version: 2009b
% Created: 2012.05.23
channelidx = controller.addCommandChannel(channelname);
BoatDTConnection.m
%**********************************************************************
**
%* Copyright(c) 2007-2008 Robotics Systems Lab, Santa Clara University
%* All rights reserved.
%**********************************************************************
**/
%**********************************************************************
***
%* FILENAME: BoatDTConnection.m
%*
%* DESCRIPTION:
% Connects Matlab to robots using RobotEq board(eg. robokayaks,
% ASV,rowerwerx) using the Data Turbine
%
% robot = BoatDTConnection(robotName, ipAddress,
tcpPort,motorConstant)
%
% @param robotName(string) :robot name
% @param ipAddress(string) :ip address of the data turbine
server
% @param tcpPort(string) :tcp port used by the data turbine
% @param motorConstant(double): scales output actuator commands
for
% different RobotEQ boards
% @returns robot(BoatDTConnection): robot object

79. 71
%
%* SPECIAL CONSIDERATIONS:
% In our current controller we output fwdVelocity in the range
from
% -1m/s to 1m/s and rotVel:-1rad/s to 1rad/s and we
experimentally
% found that translates in 30/127 of AX3500 forward output(2x
that on AX2500).
% Rotational output is a bit harder to determine so we are
playing
% with this number. Do not exceed commanded output of 127
%
% Use the following motor constants for RobotEQ controllers to
make
% them act as if they are the approximately the same:
% AX2500: motorConstant=2.0
% AX3500: motorConstant=1.0
%
%*
%* MODIFICATION HISTORY:
%* YYMMDD Author/Developer Reason
%* ------ ---------------- -----------------------------------------
--
%* 080207 op Added more code comments
%*
%**********************************************************************
**/
function
self=BoatDTConnection(robotName,ipAddress,tcpPort,motorConstant)
self = create_object;
robot = RobotDTConnection(robotName,ipAddress,tcpPort);
%limiting constants for boat engine commands. Do not exceed 127
FWD_MAX_PERCENT_PUSH=125.0;
ROT_MAX_PERCENT_PUSH=125.0;
engineFactor=motorConstant; %Compensates for boats with different
RobotEQ boards
% m_getName
%
% @returns robot name string
%%
function [robotName]=m_getName()
robotName=robot.m_getName();
end
% m_disconnect
%
% Disconnects the robot from the Data Tubine
%%
function m_disconnect()
robot.m_disconnect();
end

80. 72
% m_getTelemetry
%
% @returns telemetry:hashtable containing the latest telemetry
%%
function [telemetry]=m_getTelemetry(keys)
telemetry = robot.m_getTelemetry(keys);
end
% m_isConnected
%
% @returns result:boolean true if connected
%%
function [result]=m_isConnected()
result=robot.m_isConnected();
end
% m_send
%
% Sends velocity commands to the robot
%
% @param inputVector:1x2 vector [forwardVelocity rotVelocity]
%%
function m_send(inputVector)
%boats internally work with %forward_push and %rotational_push
% 0% 'push'=0 ; 100% 'push' = 127
inputVector(1)=sign(inputVector(1))*min(abs(inputVector(1))*FWD_MAX_PER
CENT_PUSH*engineFactor,FWD_MAX_PERCENT_PUSH*engineFactor);
inputVector(2)=sign(inputVector(2))*min(abs(inputVector(2))*ROT_MAX_PER
CENT_PUSH*engineFactor,ROT_MAX_PERCENT_PUSH*engineFactor);
robot.m_send(inputVector);
end
% m_sync
%
% Fetches the latest telemetry from the remote robot
%
function m_sync()
robot.m_sync();
end
end %object
function self = create_object
stk = dbstack('-completenames');
mname = stk(2).file;
fcn_names = scan(mname, {'m_[A-Za-z0-9_]*'});
fcns = evalin('caller',['@(){' sprintf('@%s ', fcn_names{:}) '}']);
fcns = fcns();
for i = 1:length(fcns);fcn = fcns{i};
self.(fcn_names{i}) = fcn;

81. 73
end
end
% SCAN
%
% Scans and extracts function names from an m file
% using regular expression patterns.
%
% Arguments
% file - full path to an m file to scan
% patterns - A cell array of regular expressions for function
names
% to extract
%
function names = scan(fname, patterns)
if iscell(patterns)
patterns = sprintf('(%s)|',patterns{:});
end
str = evalc(sprintf('mlint(''-calls'',''%s'')', fname));
names = regexp(str,'d+s*([AZa-z][A-Za-z0-9_]*)','tokens');
names = cellfun(@(x) x{1}, names, 'uniformoutput', false);
i = cellfun(@(x)~isempty(regexp(x, patterns)), names);
names = names(i);
end
Calibrate_robot.m
%calibrate robot in xy plane
%sets x and y to zero
%writes calibration data to the calibration file
c=[0 0];
xc=0;
yc=0;
save cali.mat xc yc
for i=1:100
Trout.m_sync();
c=Trout.m_getTelemetry({'globalX' 'globalY'})+c;
end
c=c/100;
xc=c(1,1)
yc=c(1,2)
save cali.mat xc yc
gpsxy(Trout)
clear yc xc c i
controller.m
function connect =
controller(dataturbineip,dataturbineport,controllername)

82. 74
% CONTROLLER Connect data handling controller to a ground station
DataTurbine.
% CONNECT = CONTROLLER(CONTROLLERNAME,DATATURBINEIP,DATATURBINEPORT)
returns
% a MatlabController object, which is responsible for the forwarding
of
% data to functions defined and registered to the object.
CONTROLLERNAME
% is the name that identifies the application that is sending data.
% DATATURBINEIP is the specific IP address of the DataTurbine
instance
% to be connected to, which may be 'localhost.' DATATURBINEPORT is
the
% port used to establish communication with the DataTurbine server.
% CONNECT is a Java MatlabController object.
%
% Use of this method requires that the jmatlab.jar file be included
on
% the Matlab classpath.
%
% Author: Mike Rasay
% Version: 0.1.1
% Matlab Version: 2009a
%
% handling input arguments - In the case that this function is called
with
% two arguments, it is assumed that it will be a listen only entity and
% that a command channel should not be created.
% If no arguments are specified the default is to establish 2-way
% communication with the Source being 'matlab'.
if nargin == 0
controllername = 'matlab';
dataturbineip = 'localhost';
dataturbineport = '3333';
elseif nargin < 2
error('Invalid parameter count');
end
try
connect =
edu.scu.engr.rsl.matlab.MatlabController(dataturbineip,...
dataturbineport,controllername);
catch exception
% notify the caller that the jar cannot be located
if strcmp(exception.identifier,'MATLAB:undefinedVarOrClass')
error('JMatlab Jar Error: Insure that the classpath includes
jmatlab.jar');
end
end
Crosstrack.m
%Crosstrack function

83. 75
% Author: Arjun Menon, Robotic Systems Laboratory (Santa Clara
University)
% Version: 0.1.0
% Matlab Version: 2007b
% Created: 04.13.2013
function vect = crosstrack(des_bearing,x_current,y_current, status)
persistent i;
persistent fix_x_locked;
persistent fix_y_locked;
%persistent fix_x_kayak_locked;
%persistent fix_y_kayak_locked;
%fid = fopen('Crosstrack.txt', 'at');
if (status == 0) % Checks status of Yaw Auto
On/Off. This value also determines
% the choice between yaw Auto
and Manual inside the Controller block.
i=0;
x_locked = 0; % Setting this value to 0 is
only meant to initialize desiredVal and
y_locked = 0; % the output does not matter
because once the status is 0, the switch inside
% x_kayak = 0;
% y_kayak = 0;
%xy = [x_locked y_locked]; % the Controller block does not
allow this Matlab function's data line to run.
ect = 0;
dist = 0;
vect = [ect; x_locked; y_locked; dist];
else
if (isempty(i))
i = 0;
end
if (isempty(i)) || (i==0) || (i==1) % It sometimes takes about two
cycles for CurrentVal to be updated hence it allows
% two iterations before it
locks up.
i = i + 1;
x_locked = x_current;
y_locked = y_current;
% x_kayak_locked = x_kayak;
% y_kayak_locked = y_kayak;
fix_x_locked = x_locked;
fix_y_locked = y_locked;
% fix_x_kayak_locked = x_kayak_locked;
% fix_y_kayak_locked = y_kayak_locked;
%xy = [x_locked y_locked];
ect = 0;
dist = 0;

84. 76
vect = [ect; x_locked; y_locked; dist];
end
if(i>1)
x_locked = fix_x_locked;
y_locked = fix_y_locked;
% x_kayak_locked = fix_x_kayak_locked;
% y_kayak_locked = fix_y_kayak_locked;
%//////////////////////////////////////////////////////////////////
%Calculate distance between line and a current position in order to
%calculate cross track error. dist is the absolute crosstrack value.
% if(status_kayak==0)
m = tan(pi/2 - des_bearing);
% else
% m = (y_locked-y_kayak_locked)/(x_locked-x_kayak_locked);
% angle = atan(m);
% end
b= -1;
a = m;
c = -m*x_locked+y_locked;
dist = abs((a*x_current + b*y_current + c))/sqrt(a^2 + b^2);
%calculate direction of turn for corrective Yaw.
if((des_bearing*(180/pi))<=180)
dir_val = a*x_current + b*y_current + c;
if dir_val<0
ect = dist/10;
if ect>0.8
ect = 0.8;
end
vect = [ect; x_locked; y_locked; dist];
%Logging data
% logg = [des_bearing x_current y_current x_locked y_locked dist
clock];
% fprintf(fid, '%f %f %f %f %f %f n n n n n n ',logg);
%turn anticlockwise directly proportional to dist.
else
%turn clockwise directly proportional to dist.
ect = -dist/10;
if ect<-0.8
ect = -0.8;
end
vect = [ect; x_locked; y_locked; dist];
%Logging data

85. 77
%fid = fopen('Sim1.txt', 'at');
% logg = [des_bearing x_current y_current x_locked y_locked dist
clock];
% fprintf(fid, '%f %f %f %f %f %f n n n n n n ',logg);
%fclose(fid);
end
else
dir_val = a*x_current + b*y_current + c;
if dir_val>0
ect = dist/10;
if ect>0.8
ect = 0.8;
end
vect = [ect; x_locked; y_locked; dist];
%Logging data
% logg = [des_bearing x_current y_current x_locked y_locked dist
clock];
% fprintf(fid, '%f %f %f %f %f %f n n n n n n ',logg);
%turn anticlockwise directly proportional to dist.
else
%turn clockwise directly proportional to dist.
ect = -dist/10;
if ect<-0.8
ect = -0.8;
end
vect = [ect; x_locked; y_locked; dist];
% Logging data
% logg = [des_bearing x_current y_current x_locked y_locked dist
clock];
% fprintf(fid, '%f %f %f %f %f %f n n n n n n ',logg);
end
end
end
end
%fclose(fid);
end
Depthlock.m
%Function to take the first value from Current depth and assign it as
the
%Desired depth when Depth Lock has been enabled.

86. 78
% Author: Arjun Menon, Robotic Systems Laboratory (Santa Clara
University)
% Version: 0.1.0
% Matlab Version: 2007b
% Created: 07.03.2012
function desiredVal = depth_lock(status,currentVal)
persistent i;
persistent fix_desiredVal;
%fid = fopen('depthlock.txt', 'at');
if (status == 0) % Checks status of Depth Auto
On/Off. This value also determines
% the choice between Depth Auto
and Manual inside the Controller block.
i=0;
desiredVal = 0; % Setting this value to 0 is
only meant to initialize desiredVal and
% the output does not matter
because once the status is 0, the switch inside
% the Controller block does not
allow the this Matlab function's data line through.
else
if (isempty(i))
i = 0;
end
if (isempty(i)) || (i==0) || (i==1) % It sometimes takes about two
cycles for CurrentVal to be updated with the Current value hence it
allows
% two iterations before it
locks up.
i = i + 1;
desiredVal = currentVal;
fix_desiredVal = desiredVal;
end
if(i>1)
desiredVal = fix_desiredVal;
%Logging
% depth_val = [desiredVal currentVal];
% fprintf(fid, '%f %f n n',depth_val);
end
end
%fclose(fid);
end
easytrackparser.m
function [x,y,z] = easytrakparser(data)

87. 79
% EASYTRAKPARSER Parses data from the EasyTrak (Applied Acoustic)
system.
% [X,Y] = EASYTRAKPARSER(DATA) Returns the position of the responder,
% contained in X and Y. DATA is the data (char array) provided by the
% 'trackerdatahandling' callback function containing the AAE
formatted
% output .
%
% Author: Michael "G" Neumann, Robotic Systems Laboratory (Santa
Clara
% University)
% Version: 0.1.0
% Matlab Version: 2009a
% Created: 2010.01.20
% Parse the data using strread. Since the beacon identification number
and
% the data type are integers their data is stored as an int8. Most of
the
% other variables are stored as a double, since they have floating
points.
% The time is stored as a string since it simplifies parsing the hour,
% minute, and second.
[rand beaconId dataType time x y z slantRange bearing depressionAngle
compass roll pitch errorCode] =
strread(data,'%s%d%s%f%f%f%f%f%f%f%f%f%f%d','delimiter',',');
%[beaconId] = strread(data,'%d','delimiter',',');
%hour=str2double(time{1}(1:2));
%minute=str2double(time{1}(3:4));
%second=str2double(time{1}(5:6));
%Edited by Arjun Menon on 06.20.2013 for Zeroing GPS
assignin('base','GPS_E',time(1));
assignin('base','GPS_N',x(1));
Init_X = evalin('base','Init_X');
Init_Y = evalin('base','Init_Y');
val1 = time(1) - Init_X;
val2 = x(1) - Init_Y;
assignin('base','X_E',val1);
assignin('base','Y_N',val2);
assignin('base','depth',z(1));
% disp(data);
Framtransform.m
function y = frame_transform(Force_x,Force_y,Force_V,Torque_G,yaw_r )
yaw = yaw_r*(pi/180); %Triton's measurement is in degrees, hence
converted to radians.
rot_matrix = [sin(yaw) cos(yaw) 0 0 ;
-cos(yaw) sin(yaw) 0 0;
0 0 1 0;

88. 80
0 0 0 1;];
in_vector = [Force_x; Force_y;Force_V;Torque_G];
%y = rot_matrix*in_vector;
y = rot_matrix*in_vector;
end
frametransformkayak.m
function y = frame_transformKayak(Force_x,Force_y,Torque_G,yaw_r )
% Kayak's measurement of Yaw is already in radians.
rot_matrix = [sin(yaw_r) cos(yaw_r) 0 ;
-cos(yaw_r) sin(yaw_r) 0;
0 0 1;];
in_vector = [Force_x; Force_y;Torque_G];
%y = rot_matrix*in_vector;
y = rot_matrix*in_vector;
end
gpsxy.m
%Gets GPS data from the robot
%gpsxy(robot name)
%u=[Counts robotx roboty heading]
%heading in rads -pi to pi
function u=gpsxy(robot)
raw=eye(1,4);
world=open('sim.mat');
%0 for Real World, 1 for sim
robot.m_sync();
%Real World
if(world.sim==0)
raw=robot.m_getTelemetry({'counter' 'globalX' 'globalY'
'heading'});
x=raw(1,2);
y=raw(1,3);
head=raw(1,4)*pi/(180);
elseif(world.sim==1)
%Sim
raw=robot.m_getTelemetry({'counter' 'localX' 'localY'
'amigoCompassRadians'});
x=raw(1,2);
y=raw(1,3);
head=-raw(1,4);

89. 81
end
count=raw(1,1);
if(head>pi)
head=head-2*pi;
end
u=[count x y head]';
robot.m_sync();
end
registerfunction.m
function funct = registerfunction(controller,functionname,channelname)
% REGISTERFUNCTION Associates a callback function with a specific
channel
% name.
% FUNCT = REGISTERFUNCTION(CONTROLLER,FUNCTIONNAME,CHANNELNAME)
returns
% the Java Function object that is created within this function.
% CONTROLLER is the Java MatlabController object that is created and
% returned by the 'controller' function. FUNCTIONNAME is the name of
the
% callback funtion that is to be executed when data is received on
the
% specified CHANNELNAME. This function must be called prior to the
call
% to 'start' or the communication and dispatching of the data receive
% event will not occur.
%
% The specification of the CHANNELNAME must follow the naming
convention
% prescribed by the DataTurbine where the source and channel name be
% specified (/source_name/channel_name). If the data source creates a
% connection to the DataTurbine with the name 'RemoteNode' and a
'data'
% channel, the CHANNELNAME should be specified as '/RemoteNode/data.'
%
% In the case that the callback function that is to be excuted
requires
% more than the data from the DataTurbine, this function will not
provide
% the appropriate means to registering the callback function.
%
% Author: Mike Rasay
% Version 0.1.0
% Matlab Version: 2009a
% Created: 2010.01.19
% the addSubscriberFunction method requires that the Function
parameter be
% an array
funct(1) = edu.scu.engr.rsl.util.Function(functionname);
% the data that is forwarded by the controller

90. 82
funct(1).addArg(edu.scu.engr.rsl.util.ByteArray);
% add the function to the controller
controller.addSubscriberFunction(channelname,funct);
ROVxy.m
function out=ROVxy(u)
x = 0;
y = 0;
eml.extrinsic('evalin')
x = evalin('base','X_E');
y = evalin('base','Y_N');
out = [x y];
sendcommand.m
function sendcommand(controller,channelidx,data)
% SENDCOMMAND sends command data on the DataTurbine.
%
% SENDCOMMAND(CONTROLLER,CHANNELIDX,DATA) send the DATA on the
CHANNELIDX
% on the specified CONTROLLER.
%
% This function is provided as a convenience function and the
% functionality can be acheived by explicitly calling the
% 'sendData' function of the controller Java object. The code
% contained in this function can be duplicated in a script, function,
or
% the command prompt with the same results as this function.
%
% Author: Mike Rasay
% Version 0.1.0
% Matlab Version: 2009b
% Created: 2012.05.23
controller.sendData(channelidx,data);
trackerdatahandling.m
function [x,y,z] = trackerdatahandling(data)
% TRACKERDATAHANDLING The default callback function for the acoustic
% tracker client.
% TRACKERDATAHANDLING(DATA) is the data handling callback function
that
% is registered with a MatlabController object that receives data
from
% the acoustic tracker, over the DataTurbine. DATA is the ByteArray
% object (see edu.scu.rsl.util.ByteArray) that contains the time
stamp
% and raw data received. This function is not designed to be used or
% called in a scripting fashion and serves as a utility for for the

91. 83
% underlying Java thread to throw up an event notification.
%
% This function acts as an interface to other functions that may be
used
% for data handling. The 'easytrakparser' function is called by this
% function for the parsing of data. For additional functionality,
% function calls may be included in this function or callback
functions
% may be registered with the MatlabController.
%
% See also REGISTERFUNCTION
%
% Author: Mike Rasay, Robotic Systems Laboratory (Santa Clara
University)
% Version: 0.1.0
% Matlab Version: 2009a
% Created: 2010.01.20
% extract time/data from 'data' (ByteArray)
timestamp = data.getTimes; % an array of doubles
bytearray = data.getArray; % a raw byte array
% convert the byte array to a char array
packetstring = char(java.lang.String(bytearray));
%packetstring = unicode2string(bytearray);
% convert the timestamp to a universal date string
%timestring = char(java.text.SimpleDateFormat('yyyy-MM-dd
HH:mm:ss').format(java.util.Date(timestamp(1)*1000)));
% A debug statement - display the time and data strings
global x y z;
[x y z] = easytrakparser(packetstring);
End
yawlock.m
%Function to take the first value from Current heading and assign it as
the
%Desired heading when Yaw Lock has been enabled.
%Function to lock heading based on Kayak position.
% Author: Arjun Menon, Robotic Systems Laboratory (Santa Clara
University)
% Version: 0.1.0
% Matlab Version: 2007b
% Created: 07.03.2012
% Updated: 08.08.2013 Added Kayak position based locking.
function desiredVal =
yaw_lock(status,currentVal,x_kayak,y_kayak,x_rov,y_rov,status_kayak)

92. 84
persistent i;
persistent j;
persistent fix_desiredVal;
persistent fix_desiredXkayak;
persistent fix_desiredYkayak;
persistent fix_desiredXrov;
persistent fix_desiredYrov;
%fid = fopen('yawlock.txt', 'at');
if (status == 0) % Checks status of Yaw Auto
On/Off. This value also determines
% the choice between yaw Auto
and Manual inside the Controller block.
i=0;
j=0;
desiredVal = 0; % Setting this value to 0 is
only meant to initialize desiredVal and
% the output does not matter
because once the status is 0, the switch inside
% the Controller block does not
allow the this Matlab function's data line through.
else
if (status_kayak ==1)
if (isempty(j))
j = 0;
%desiredVal = 0;
end
if (isempty(j)) || (j==0) || (j==1) % It sometimes takes about two
cycles for CurrentVal to be updated hence it allows
% two iterations before it
locks up.
j = j + 1;
desiredXkayak = x_kayak;
desiredYkayak = y_kayak;
desiredXrov = x_rov;
desiredYrov = y_rov;
fix_desiredXkayak = desiredXkayak;
fix_desiredYkayak = desiredYkayak;
fix_desiredXrov = desiredXrov;
fix_desiredYrov = desiredYrov;
Y_e = desiredYkayak-desiredYrov;
X_e = desiredXkayak-desiredXrov;
ang = atan2(X_e,Y_e);
if ang<0
ang = ang+(2*pi);
end
%radVal = pi/2 - ang;
desiredVal = (180/pi)*ang;
end
if(j>1)
desiredXkayak = fix_desiredXkayak;
desiredYkayak = fix_desiredYkayak;

93. 85
desiredXrov = fix_desiredXrov;
desiredYrov = fix_desiredYrov;
%Logging data
Y_e = desiredYkayak-desiredYrov;
X_e = desiredXkayak-desiredXrov;
ang = atan2(X_e,Y_e);
if ang<0
ang = ang+(2*pi); % Offsetting values
because controller assumes 0-360 degrees clockwise rotation
end % whereas atan2 does 0-
180 and -180 to 0 clockwise. Kayak yaw measurement also behaves
%radVal = pi/2 - ang; % like atan2.
desiredVal = (180/pi)*ang;
%desiredVal = (180/pi)*desiredVal;
end
else
if (isempty(i))
i = 0;
end
if (isempty(i)) || (i==0) || (i==1) % It sometimes takes about two
cycles for CurrentVal to be updated hence it allows
% two iterations before it
locks up.
i = i + 1;
desiredVal = currentVal;
fix_desiredVal = desiredVal;
end
if(i>1)
desiredVal = fix_desiredVal;
%desiredVal = (pi/180)*desiredVal;
%Logging data
%yaw_val = [desiredVal currentVal];
% fprintf(fid, '%f %f n n',yaw_val);
end
end
%fclose(fid);
end
ZeroGPS_ROV.m
%Arjun Menon
% RSL 2013
% Function to zero GPS whenever needed.
function [x,y,z]=dataturbine

94. 86
x = 0;
y = 0;
z = 0;
eml.extrinsic('evalin')
G_x = evalin('base','GPS_E');
G_y = evalin('base','GPS_N');
%z = evalin('base','depth');
assignin('base','Init_X',G_x);
assignin('base','Init_Y',G_y);
%assignin('base','depth',z(1));