UNH Underwater ROV

Final Report

University of New Hampshire Submitted to: W. Thomas Miller

Date Submitted: 10/21/2013

2013-2014 Underwater ROV Team: Nick Geist

Matt Sweeny Tyler Fausnacht

Chris Barr Sean Gribbin Alex LeBoeuf Sean Leighton

Ryan Cahill Firat Eren

Eric Boudreau

ECE Faculty Advisor: W. Thomas Miller, III, Ph. D. ME Faculty Advisor: May-Win Thein, Ph. D.

Courses Involved: CS 415, CS 416, CS 515, CS 520, ECE 541, ECE 649, CS 725 Project Completion Date: May 2013

2

Table of Contents

Abstract 3

Introduction 4

Methods 5 – 7

Results 8 - 10

Discussion and Conclusions 11 – 12

Appendix 13

3

Abstract

Our interdisciplinary team comprised of mechanical engineering, computer science, and computer engineering students was tasked with building an ROV (Remotely Operated Vehicle) which can be placed into water and controlled from land. This vehicle is entered into a competition in Michigan called the MATE ROV Competition in which we will have to complete certain tasks with the ROV underwater. These tasks simulate real-life situations in which commercial ROV’s can be used. They include reading the name of the ship in a simulated shipwreck, bringing objects underwater to the surface using a mechanical arm, and taking objects down to the simulated ocean floor and placing them in specific locations, among other things.

Our team of ten different students from three different disciplines is broken down into four teams which will focus on different parts of the ROV. They are the chassis, propulsion, controls, and tether teams. Each team developed their own parts of the ROV which were assembled once design, building, and testing of each of the parts were complete. My contribution involved wiring the entire ROV as I was the only ECE member of the team. I also dealt with all of the electrical components including the power converters, H-bridges, and the Arduinos, among other things. I worked closely with the rest of the controls team to troubleshoot any problems that occurred with the electronics or embedded code on the ROV. It was successfully tested to be waterproof and controllable underwater with a working video feed on May 14th, 2014. Improvements will be made until the date of the competition on June 26th, 2014.

4

Introduction

An ROV, or remotely operated vehicle, is an unmanned underwater vehicle which is designed to complete tasks which might otherwise be impossible or far less feasible for humans to complete. The international MATE competition, held in Thunder Bay, Michigan, will test the team’s ROV by simulating such tasks. A simulated shipwreck is placed at the bottom of the pool and is the center of focus for various challenges. These can be anything from using the ROV’s mechanical arm to bring an object to the surface, to collecting microbial samples underwater, to reading the name of the “shipwreck” from its surface.

The team took all proposed challenges into account when designing the ROV. Six thrusters were used this year as opposed to four in previous years as this would make the ROV easier to maneuver in tight spaces. Also, the tether is designed to be neutrally buoyant so it doesn’t interfere with the movement of the ROV. The pool depth, width, and length also dictated the length of the tether which ended up being 65 feet long. The design of the chassis was revised multiple times to attempt to make handling the ROV easier in tight spaces.

5

Methods

The controls team comprised of one computer engineering student and two computer science students is responsible for designing, building, and testing the controls of the ROV. This software and hardware will allow one pilot to control the ROV from a computer on land with a PlayStation 3 controller.

Figure 1 is a flow chart showing how the controls team originally planned to send data between devices. Taking into account the needs of the ROV as a whole and the need for our graduate advisor’s Ph.D. research, this design changed and an updated flowchart is shown in Figure 2.

Figure 1: Original Block Diagram of Control Flow

6

The OBC (On Board Computer) is still a BeagleBoard XM as it is inexpensive, but also powerful and contains all of the necessary ports. It is a bridge for communication between the pilot and the Arduinos. The pilot uses the UI and the PlayStation 3 controller to send commands from the computer on land to the OBC. This information is processed and sent to the thruster Arduino, which contains the algorithm for controlling each of the six thrusters. The Arduino then sends PWM and directional signals to the H bridge motor drivers, which cause the ROV in to move in the direction the pilot intends. The IMU is also connected to the OBC through a USB port, where the data is processed and sent to the PC for the pilot to view the pitch of the ROV underwater.

Changes to the control scheme include an entirely different Arduino to handle the sensors’ data. The sensor Arduino receives signals from the sensors, which are sent to the OBC, processed, and sent to the UI on the computer on land. These sensors will be able to detect temperature, depth, pressure, and anything else that will be necessary to help the pilot understand the current condition of out underwater vehicle.

Figure 2: Modified Block Diagram of Control Flow

7

The software that needs to be developed will be a GUI to display information about the current state of the ROV, software for the on board computer, and software for the Arduino. These parts need to be wired together and will get their initial power from a 48 volt source.

GUI Design

Display sensor information

Show pitch of the ROV and other IMU data

Alert on malfunctioning hardware

Optional control of thrusters

Camera movement

OBC (On Board Computer) Software

Send data to computer on land for processing

Send commands from pilot to arduino for thruster control

Obtain data from sensors and IMU

Send camera feed to computer on land

Arduino Software

Algorithm for control of thrusters based on input

Send PWM signals to motor drivers for thrusters

Send directional signals to motor drivers for thrusters

Keep ROV steady in water by locking on to current depth information

8

Results

GUI

The GUI from this year was built off of last year’s code, but greatly improved upon. Some issues with last year’s code were that there was no segment for the camera feed and it was viewed in a separate window. This just didn’t make much sense. The entire top left quarter of the GUI was a big logo and didn’t serve any purpose at all. The top right part of the GUI was meant for thruster control by using sliders but this didn’t seem like a very intuitive way to control the ROV. Last, the box showing the orientation was just a single green wire frame which didn’t have any indication on which part of the box actually represented the front of the ROV.

All of these issues were fixed in this year’s model. A camera feed was incorporated into the top left part of the GUI so the driver of the ROV doesn’t have to watch two screens to control it. The camera feed can be started and stopped with different buttons and a recording feature is also built in. The sliders for the thruster control were removed when the controller was incorporated into the code. They were replaced with a box showing which pair of thrusters was selected and which way they were moving. Speed of the thrusters is also shown. These portions greatly help the driver understand how to best control the ROV from its current state. Last, to make the orientation part of the GUI more intuitive, an arrow was added to the box showing the ROV’s orientation which indicates how the ROV is positioned in the water relative to its front. An image of the complete GUI is shown in Figure 3.

Figure 3

9

Thruster Control

The major difference between last year’s ROV and this year’s is the thruster configuration. This year the ROV has six thrusters instead of four, adding side to side movement along with forward and back movement and up and down movement. This could be very convenient for movement in tight spaces. The PlayStation 3 controller can be used to control the thrusters directly. When the X, circle, or square button is pushed, a pair of thrusters becomes controllable. The left joystick can be moved from left to right to speed up the pair. More specifically, when the joystick is all the way to the left, the thrusters are off and when it is all the way to the right, the pair is at full power. This has so far proved to be a huge improvement over last year’s design.

As the GUI receives the commands from the PlayStation 3 controller, it will send a packet to the OBC through the Ethernet cable in the tether containing which thrusters to move, how fast to move them, and in which direction to move them. The OBC will forward the packet through USB to the serial port of the thruster Arduino where the commands will be interpreted. The directional signal will determine whether a high or low signal should be sent to the directional pin on the H-bridge corresponding to each thruster. The part of the packet containing the speed will be taken as a value from 0 to 255 and will control the pulse width sent to the H-bridges accordingly. For example, a value of 255 would set the selected pair of thrusters to full power.

The H-bridges used are Pololu high power motor drivers. The pins used for control are a ground pin grounded at the thruster Arduino, a pulse width pin for the amount of current to put out, and a directional pin to control the output pins and which ones will have positive or negative current. As input voltage, 18.5 volts are supplied from the 48 volt to 18.5 volt DC to DC converter aboard the ROV. The recommended voltage is 19 volts DC, however 18.5 volts was as close as the group could find.

IMU

As the competition isn’t until late June and the IMU isn’t actually required to qualify for the MATE competition, it hasn’t been fully integrated into the ROV yet. This is due to the fact that there is currently no housing for it at the ROV’s center of mass. Placement of the IMU at the ROV’s center of mass will help the pilot get a more accurate reading of the pitch of the ROV. The IMU chosen is the same as last year’s, a 9 Degrees of Freedom Razor IMU which connects to the BeagleBoard xM through a USB port on an FTDI basic breakout board. This saves a lot of trouble with having to pass the signals through an Arduino first.

The IMU has three basic sensors on it. There is a triple-axis digital gyroscope, a 13-bit resolution triple axis accelerometer, and a triple-axis digital magnetometer. The gyroscope provides the data which the pilot views in the bottom left of the GUI. This will be the orientation of the ROV. The accelerometer will be used later on when the project’s graduate

10

advisor needs the ROV for his research. As the research involves an autonomous leader-follower pair of unmanned underwater vehicles, each vehicle should be able to find out the acceleration of the other one to adjust its own thrusters or direction.

Sensors

The same basic types of sensors in last year’s model will be used. However, this year the group is using combination humidity and temperature sensors from Maxdetect. A sensor will be placed in each of the three electronics tubes to monitor their safety. They need a two second delay between data transmissions, but this is not a huge problem. Barring a massive quantity of water flowing into one of the electronics tubes all at once the pilot shouldn’t need a shorter timespan between readings. The data from each sensor is collected as a stream of 40 bits by the sensor Arduino. These 40 bits represent 16 bits of temperature data, 16 bits of humidity data, and an 8 bit checksum. This data is passed through the BeagleBoard xM up to the GUI where the bits are broken down into temperature and humidity readings, then displayed.

Camera Feed and Control

The camera used for this year’s ROV is a Microsoft Lifecam with a standard USB output. The camera is mounted on a small plate connected to a servo to enable the pilot to move it up and down. It is housed in its own polycarbonate tube on the front of the ROV and its wire runs out of the tube, through one of the main electronics tubes, to a USB booster in the tether, and finally up to the surface to the PC. This original design was used to make the video feed as simple as possible. Unfortunately, the group who qualifies teams for the MATE competition very recently stated that this method is not allowed and the camera needs to be powered at the ROV itself. This sent us back to the drawing board and a new method is still being determined. A possible and likely solution would be to power the camera from the BeagleBoard xM on the ROV through one of its USB ports, then send the video data through the Ethernet cable which is already used to send data between the PC and the ROV.

The servo which moves the camera is controlled by using the PlayStation 3 controller. By pressing a button, a command will be sent to the BeagleBoard xM and will be routed to the sensor Arduino. The sensor Arduino will then send a pulse width modulated signal to the servo to move in the direction that the pilot intends.

Communication between Components

Two different protocols were used for communication between components both on the ROV and on land. The OBC uses USB 2.0 to send and receive data from the Arduinos through their serial ports and to receive data from the IMU. It could potentially be using USB 2.0 to relay the camera feed as well if testing proves that it is a feasible method in our control scheme. The PC on land and the OBC use standard TCP/IP protocol to send messages between them. TCP involves sending packets between devices and managing the connection between them. TCP can also handle missing or corrupt packets if something goes wrong during transmission.

11

Discussion and Conclusions

The ROV was tested to be waterproof and controllable using the PlayStation 3 controller on May 14th, 2014. Its six thrusters can move the ROV around in the pool although the weight distribution is currently a little uneven and the ROV tilts upwards towards its nose. This will be fixed in the near future. A difficult task at first, a working video feed was established from the webcam aboard the ROV, through the 65 foot long tether, and to an e-SATA port on the computer on land. It sounds like a simple thing to do, but it proved to be one of the most time consuming single tasks for the controls team. Things to be accomplished before the competition on June 26th, 2014 include creating code to move the servo for the camera, wiring the servo to the Arduino, mounting the mechanical arm, and wiring the servos and writing the code to control the mechanical arm. Sensors also need to be added to support the work of our graduate advisor at some point during the summer.

Mission tasks for the ROV at the competition include determining the dimensions of the simulated shipwreck, entering it, creating a photomosaic of its surroundings, retrieving a ceramic dinner plate from inside, and estimating the amount of mussels on the outside. The ROV was created to be a few inches smaller than originally designed which will help the pilot navigate very easily inside the shipwreck. The mechanical arm still needs to be implemented but will be a very important part of the underwater operations for the competition. Also, some kind of image processing code will have to be created to make the photomosaic. Looking back, the most important thing that I would have changed is doing more research on sending a video feed through a 65 foot cable. The original cable used USB boosters to send the signal this far, but it failed as it had to be waterproofed in too many places and the waterproofing didn’t last. A cat-5 cable was substituted in its place with USB to cat-5 converters on each end and works nicely.

The chassis, propulsion, and controls teams all worked extremely efficiently considering time restraints each group could spend on the project. The most difficult parts of the project were the unforeseen challenges. Last year’s code was planned to be a solid base for the code this year, but it was a little messier than originally thought. The decision was soon reached that it just made more sense to start from scratch. The chassis team also had some issues with waiting for time in the machine shop and waiting for parts in the mail. The last major problem is the issue of the camera feed not being allowed to run straight back up to the surface. This has yet to be resolved.

Working as an interdisciplinary team allowed us to build an incredible project and also taught a lesson of working around things that might not come up in a strictly electrical and computer engineering project. In the entire curriculum of computer engineering, not once was waterproofing an issue. Things like weight distribution or buoyancy never had to be considered either. These types of factors that come along with other disciplines made working on the project even more interesting.

12

Although it wasn’t an electrical and computer engineering task waterproofing became the biggest issue for everyone. At a depth of about 20 feet, the pressure gets so high that water finds its way in through the most unexpected places. At one point in waterproof testing, water got into a tether connection and managed to trickle through the sheath of a 48 volt power cable. It began dripping dangerously close to the terminals of a power converter but the ROV was pulled from the water quickly enough that no harm was done. More epoxy was applied to the connection to make sure that this couldn’t happen again.

My very broad job description was choosing, wiring, testing, and troubleshooting all of the electrical connections on the ROV. Most of this went very smoothly as the design was kept as simple as possible. This was partially due to space constraints inside the electronics tubes and also the desire to keep the wiring as neat and easy to follow as possible just in case anything went wrong. I basically managed the power distribution throughout the ROV as it came in from the 48 volt source through the tether. This included wiring and troubleshooting the DC to DC power converters, the Arduinos, the BeagleBoard xM, the camera, the USB to Ethernet converters, the H-bridges, the thrusters, and the sensors on board. I worked with the propulsion and controls teams to make sure that the system of powering the thrusters would be as simple and efficient as possible. All six thrusters work very well and have been tested in the water. The most daunting task was getting the video feed to work. The original idea was to use USB boosters to push the signal along the tether. This left too many places in the tether for water to get in though, and the idea was scrapped. The replacement cable involved soldering a few connections between the Ethernet to USB converters and the USB hub on board. An Ethernet cable now carries the signal from the camera to the surface. Had more research been done on the tether though, this could have easily been avoided. It is much easier to send a USB signal through an Ethernet cable and convert it to USB on both ends than it is to use multiple USB signal boosters and try to waterproof them at each connection point throughout the tether.

13

Appendix

OBC - On Board Computer

GUI - Graphical User Interface

PWM - Pulse Width Modulation

IMU - Inertial Measurement Unit

Pololu High-Power Motor Driver 18v15

BeagleBoard-xM

9 Degrees of Freedom - Razor IMU

Arduino Mega 2560

VI-200 & VI-J00 DC-DC Converters