HOBBIES

Remote controlled submarine for exploring Ontario's lakes.

1. I was intrigued with the idea of building a fairly unusual device, with a fair number of unique engineering challenges.  Also, I have a mild phobia of deep water, so this project is cathartic for me, and has allowed me to explore the bottom of my childhood lake in northern Ontario from the relative safety of a boat.

1. Materials Science:

   • Waterproofing the hull to withstand depths of 70 feet or 20 metres (fresh water)

   • Providing sufficient maneuverability

   • Reliable communication with the operator

   • Monitoring / Controlling humidity and temperature levels inside

2. Hardware:

   • Balancing power consumption with device capabilities​

3. Software:

   • Setting up Node.js

   • Authoring balancing/steering software to ease operations of the vehicle

   • Managing real time sensor data

Given the depths (70 feet or 20m) I planned to take the ROV, I knew I needed to design the hull to be able to withstand 2 atmospheres of pressure, or about 30 psi.  I did not have the engineering background to know how to design for these pressure levels, so there was a lot of initial research and trial and error involved.

​

Graduated testing environments.  1) bathtub 2) shallow lake test (3-5 feet deep)  3) Gradual decent to 15 feet

Each test is comprised of: time (30 mins+), maneuvering in all directions, constant high-bandwidth communications to ensure the data connection is reliable.  Constant monitoring for leaks.

Results: Early tests revealed the rubber gasket I had originally designed for the front window did not provide an adequate seal.  Replacing with a softer material, "EPDM rubber", made for a better seal.  The acrylic dome I originally chose, developed stress fractures where I had drilled mounting holes. Replacing with a thicker, flat piece of acrylic, and placing a large steel washer on top of the acrylic (to ensure the heads of the mounting bolts do not apply uneven stress on the acrylic resolved the issue.

The servo for the robot hand seized (probably due to an excessively thick grease I placed in the gear box for waterproofing), a new approach was used with uses a lighter oil and 3 types of waterproofing for the case: liquid rubber, liquid black tape, and a thick balloon(!) glued over the entire unit.

Humidty was a slight problem.  Assembling the unit on a hot summer day, introduced a certain moisture content in the air inside the ROV.  When you dive deep, the pressure differential causes the moisture in the air of the ROV to condense, and cloud the acrylic lens (making it more difficult for the camera to get a clear image).  Adding silica gel packs/desiccant inside the ROV helped to absorb enough of the moisture to prevent fogging.

​

Waterproofing the holes in the hull where the wires pass through was a challenge.  Ultimately, I learned that water can penetrate the shielding of the wire, so it's important to strip the wire down to the bare metal and coat with a heavy layer of marine epoxy.  This will prevent water seepage.

​

The only remaining issue I have is a convenience one: There's no external power switch or charging terminals.  So, I currently have to fully disassemble the front lens of the ROV in order to access the internals and power the unit on and off or charge the LiPO battery.  I looked into various ways I could expose the battery terminals to the outside of the hull, but haven't found a solution (yet) that I would be happy with.

​

Credit to the kind and helpful people I worked with online to overcome my material science issues:

Bennachie @ homebuiltrovs: http://www.homebuiltrovs.com/rovforum/viewtopic.php?f=13&t=1975

How to seal wire exits in the hull: http://www.homebuiltrovs.com/howtosealingwireexits.html

​

The advancements we've seen in IOT devices over the past 10 years is what made this project feasible for the hobbyist.  Now, one can purchase small, inexpensive components that can achieve the required functionality only dreamed of in the past.  Balancing performance and power consumption was the main challenge here.  A Raspberry Pi was chosen to be the main "brains" of the device.  However, there were a couple of reasons I needed to add the PWM daughterboard: 1) the Raspberry Pi has a limited number of I/O ports, and it's ability to control realtime analog devices was not sufficient for my needs.  The PWM board I selected has 16 I/O ports, and can easily handle smooth control of analog devices (servo and motor control).  I chose brushed bilge pump motors to act as thrusters for the ROV.  One of the reasons I went in this direction is because they are designed to operate in wet conditions.  Although they operate well enough, if I were to do it again, I would probably choose brushless motors (due to lower power requirements).  The L298N motor controllers are adequate to drive the motors, but there is a fairly large voltage spike when engaging the motors.  In my initial design, I used a lower amperage battery and was experiencing constant reboots from the Raspberry Pi (it likes a constant voltage!)  Using a powerful LiPO battery seems to have fixed the issue.  However, if I experience any more stability issues, I may need to have two separate batteries.  One for the electronics, and one for the motors/servo.

My background is in software.  So this challenge was fun and comfortable for me.  Using Linux and Node.js on the Raspberry Pi was a joy.  The challenges I faced here: having a reliable way of recovering from SD card corruption.  The frequent reboots I experienced during testing (due to voltage spikes) caused the SD card to become corrupt (this is a common issue with unstable Raspberry Pi / Linux environments).  Once I was happy with the setup, I put together a recovery process for quickly re-flashing a working copy of my setup.  The user interface I designed for the operator to use had two main requriements: 1) keep the ROV level as it manuvers around  2) have the user interface reasonably simple.  The problem occurs, as you move around under water, the ROV is subject to rolling and other generally uneven movements.  Using the onboard accelerometer, this can be detected and quickly dealt with.  Thus, slightly adjusting the speed of the motors to compensate for roll is the main challenge I had to overcome.  I initially didn't know how serious of a challenge this will be, so I needed to design the software in advance to be able to handle small adjustments to how this will work in practice during dive tests.