Despite having my Raspberry Pi OpenROV, I missed some features of the Nøkken MKIII from 2012.
The main problems I've experienced are entangling the umbilical cord around rocks and other protrusions, and the fact that the ROV is very sensitive to currents.
It would often act as a drift anchor, and end up somewhere in the water column, with no means of effective propulsion. Also, I wanted something more flexible,
which didn't require a boat to use. This lead to the idea of a heavy ROV suspended from a buoy, which can drive around on it's own accord. The buoy contains
a motor to lift and lower the ROV, while the ROV contains thrusters for horizontal movement. A carefully designed/selected elastic band connecting the ROV
to the umbilical could serve to dampen the effect of waves. Together, this system should allow for exploration from land. As an intermediate step towards
this goal, I decided to resurrect the MKIII ROV concept. The new ROV can be connected to the old MKIII tether system to save some work, and verify the ROV portion of the system before working on the tether buoy unit. The ROV will have thrusters for yaw and forward/reverse, but otherwise function as a drop camera. The thrusters should be strong enough to propel both the ROV and future buoy forward. Until the motorized buoy is developed, this ROV will function like the MKIII in that a boat is required to get the ROV in position.
All required source files for this project can be found on bitbucket, ROV_MK4 Master. This should also include complete BOMs.
Since building the ROV MKIII, the Raspberry Pi platform has become so powerful that it can replace a laptop originally used in this application. Drivers for the EasyCap module already exist for Linux and were supported by the Raspberry Pi operating systems I considered. The Bluetooth communication with the PS3 controller could simply be ported from my Raspberry Pi based OpenROV project. A FPV video transmitter was used for navigation video, also as was done for the OpenROV. Next the communication between
the tether and ROV needed to be developed, which spawned it's own project, the
Integrated RS-485 Interface for Raspberry Pi Boards.
After getting this to a level I was satisfied with, the rest of the technology in the project was simple enough. I had the chance to try my hand at some
mechanical design, and designed the ROV body to be constructed from plexiglass plates in a few standard thicknesses. These parts are glued together using
Plastruct Plastic Weld glue, and seal against a cylinder body using o-rings.
Hardware
ROV Unit
The required features of the ROV "brainboard" are:
SMPS for converting battery voltage to 5V
RS-485 converter
Small video converter circuit/balun
ESCs, with control microcontroller (I2C)
Programming connection between Raspberry Pi and microcontroller
DAC for controlling LED light levels
Wireless interface to operator
These features were realized with a resistive divider to measure battery voltage, 14V to 5V buck converter, hobby grade electronic speed controllers (ESC),
hall sensor for external signaling, integrated RS-485 interface, and ATmega168 microcontroller.
The role of the microcontroller is to generate PWM signals to control the ESCs, PWM signal for LED intensity, ADC for reading the battery voltage, and monitoring
the hall effect sensor. The microcontroller also controls the reset pin of the Raspberry Pi, and is configured so the raspberry pi is reset when a magnet is
brought close to the hall effect sensor. This is so the ROV can be reset in the event of a fault, without needing to break the o-ring seals in the field.
The ATmega168 is programmed directly from the Raspberry Pi through some of the available GPIO pins, with the use of AVRdude. LED intensity is controlled
using an analog signal, which is provided by the microcontroller through a filter. The LED units themselves handle PWM dimming based on this signal.
The video signal is converted using a video balun, extracted from a device similar to the LTAB4030TP video converter. These units are designed for sending
analog video signals over Cat5 cable. For my board I simply unsoldered the raw transformer, and incorporated in into the finished ROV PCB. Power to the
Raspberry Pi Zero module is supplied directly into the header pins. The Raspberry Pi converts this down to 3V3, and provides it back to the brain board to
power the microcontroller, RS-485 logic, and hall-effect sensor. The ROV unit was designed to use four 26650 cell sized batteries, mainly because I had these already from the Raspberry Pi based OpenROV project.
Mechanical Design
The body of the ROV was designed around a 80mm inner diameter, 200mm long acrylic tube, with 5mm thick walls. I liked the sealing design of the OpenROV, so I opted for something very similar in my own design. The end caps consist of stacked plates of two different thicknesses. Three inner plates to hold an O-ring which seals against the tube, and a number of plates on the end to support either the camera view port, or tether cabling. All of the parts were designed in OpenSCAD, which is a tool for programmatically defined shapes. I like the programming aspect of the tool, since it is very easy to make designs fully parametric, and also compare changes between part revisions.
The parts are designed to be either milled, or laser cut from 3 and 6 mm acrylic sheet. Some of the parts are meant to be glued to the acrylic tube, and the rest are held together using threaded rod. To glue the end caps together I used Plastruct Plastic Weld, which has very low viscosity and evaporates quickly. This ensures the plates are glued together with a good seal, and most importantly don't change size due to the glue between plate layers. Regular 5 minute epoxy is used for more structural gluing of parts, and creating seals for later casting. The wire channel in the back end cap is filled with 30 minute epoxy, after the depth sensor hole is plugged using 5 minute epoxy. I opted to embed the depth sensor in the end cap, which immediately proved to be a bad idea since I accidently purchased the 2 bar sensor instead of the 30 bar sensor. Other than that two M2 bolts are glued to the front cap, so the camera has something to be mounted on.
The two end caps displace a significant amount of air when sealing the tube, so simply pushing them both in will create overpressure inside the tube. This will slowly push the end caps out (unless submerged underwater). To avoid this I included a small 1mL syringe plunger hole in the wire end cap, meaning the ROV can be assembled, and the the tiny plunger can be inserted at the end. Since it displaces so little volume, it doesn't increase the pressure a significant amount. As mentioned above the depth sensor is embedded in the end cap. An alternative to this is to feed the depth sensor wires out with the others, and simply route them to the back of the end cap again to a stand-alone sensor. I would recommend this in the next revision of the design.
After designing, assembling, and testing the acrylic plate based body, I tried 3D printing a PLA ROV body for the next tests. This was a pure pleasure compared to the acrylic plate body, as I had much more freedom in the design. The body design is based around clamping the external parts to the tube, so they can be removed at any time, even in the field. To get a stable connection to the housing tube, I cut apart bicycle inner tubes to make long rubber strips roughly 1mm thick. These are placed under the 3D printed parts, which are then screwed down to clamp the housing tube. This works very well, and holds the tube tightly without cracking it, and without losing holding force when wet.
The only downside I've seen so far is that the internal structure of the 3D printed parts will fill with water eventually, which is slowly released as the ROV body dries. This process can take weeks, and in the mean time salt is precipitated out of the body, which rapidly corrodes the metal parts. So unlike the acrylic ROV body which could be rinsed in fresh water, dried, and put in storage with no further thought, this ROV body requires some more diligence. I think the best solution for long term storage is to dissemble the metal parts from the body, so the salt can be released without damaging anything. Definitely a disadvantage to using a 3D printed body.
LED Light Cubes
I designed my own LED cubes to provide illumination for the ROV. These are based on the same driver and LEDs used for the Raspberry Pi based OpenROV project. The small PCB has a little heatsink mounted on the back, and is encased in epoxy to become completely water-proof. I'm not satisfied with their performance, and would recommend designing something different.
Tether Unit
As for the tether, the electronics were more or less off the shelf components cobbled together. A Raspberry Pi 3 was used for it's processing power and
Bluetooth radio, coupled with the RS-485 interface. Some of the GPIO pins were connected to
two LEDs, and a switch, to indicate the system status and optionally shutdown. A video transmitter for hobby FPV use was connected to the analog video output
of the Raspberry Pi, allowing for remote viewing with FPV goggles. The video signal from the ROV is connected to another video balun, and from here fed into
an EasyCap module. The EasyCap module converts analog video to digital, and has a USB interface. With this unit the video feed can be viewed on the
Raspberry Pi unit. Finally a small switch mode power supply unit is used to convert the battery voltage to a stable 5V for the Raspberry Pi. Everything is
glued in place, with some 3D printed stands in various places to assist fastening. The main housing was purchased on Aliexpress, and provides decent protection
against splashes of water. The main body of the tether reel was something I put together myself, which I sadly kept no drawings of. It is documented in
the ROV MKIII project however.
In hindsight, the use of an EasyCap module is redundant, along with the entire Raspberry Pi unit in the tether. The same functionality could be
achieved by directly connecting the analog video feed to the video transmitter, and using a microcontroller to generate the control data sent over RS-485.
The FPV goggles I use have a built in DVR function, allowing me to record video directly from the goggles. Video is also currently recorded from internally
in the ROV also, meaning the third option of recording from the tether is redundant in this case. However, if the ROV were simpler, such as the original
ROV MKII, and no pair of goggles with DVR built in were accessible, then use of an EasyCap is a good idea. Part of the original idea was to send video data
over RS-485 as well, removing the entire analog video path in the umbilical cord. This is still underway.
Taking this into account, I designed a ESP32 based tether control unit. It simply connects to a PlayStation controller over Bluetooth, and sends control commands to the ROV over an RS-485 interface. The analog video feed is routed directly to the video transmitter and FPV goggles. The ESP32 uses an Arduino PS3 controller library from jvpernis.
Motorized Reel
Since the ROV doesn't have any built-in buoyancy control, or lift thrusters, the reel functions as the altitude control. An important part of the future system is motorizing it so the entire unit can be remotely operated. I found Aliexpress had a wide range of geared DC motors available for sale, in different RPM and torque combinations. The load torque on the shaft is given by the radius of the reel, and the weight of the ROV:
t [Nm] = radius [m] * m [kg] * g [m/s^2]
t [kg * cm] = t [Nm] * 10.19716
For my ROV system this worked out to about 18 kg-cm of load torque. Next I checked how long it would take to reel the ROV up from 20 meters depth at various reel RPMs:
circumference [m] = 2 * Pi * r [m]
v [m/s] = (omega [RPM] / 60) * circumference [m]
Going through the available motors, I settled on the 600JSX92-4468, which could do 60 RPM and handle a load of 30 kg-cm. This provides an adequate load margin, and acceptable reel speed. For my system it would take roughly 50 seconds to pull the ROV up from 20 meters. After testing I reduced the pulley wheel ratio slightly for lower RPM and increased torque, for better altitude control near the bottom. This motor can draw up to 10A when stalled, so I needed a beefy H-bridge for controlling the motor direction. I found the BTS7960 was rather commonly available, and had plenty of margin, so it was chosen. I wanted the entire assembly to use as little space as possible, which meant the motor should be mounted beside the axle. With the motor and main axle in parallel, coupling can be done using gears or pulleys, the latter being more tolerant of the spacing between the two axles. Since I expected the loading to be relatively high, I opted for a timing belt which in my mind will be less prone to slipping due to the teeth in the belt. I'm not sure if this is the intention of the teeth, but it works. I choose a 20mm wide HTD5M belt, to get as much belt width as I could fit in the housing. A 5M-20T pulley was used for the motor, and a 5M-30T pulley for the main axle. To mount the motor inside the housing, I had a few requirements. The motor had to be adjustable so the belt tension could be set, it had to all be mounted and adjustable from the front, and it all had to fit inside the housings I was able to find on Aliexpress. I eventually ended up designing a series of plates which could be milled from aluminium, and had slots and nut traps required to fasten the motor, and allow the motor to slide up and down in order to adjust belt tension. I'm quite satisfied with the end result.
I retrofit a steel 20mm pipe as the main axle in the existing tether assembly from the ROV MKI, with 6804-2RS ball bearings to reduce friction. These fit nicely into the 32mm holes from the original plastic pipe axle. Various 3D printed parts were made to hold the ball bearings in place, and fasten the reel to the main axle. The reel fastener is a clamp, which clamps down on a small strip of rubber between itself and the axle. This provides ample friction, and allows some play in the clamp adjustment. The clamp itself is screwed to the reel. The steel pipe I had purchased was not made with precise machining, and I measured it to 20.2mm, which is 0.2mm more than the inner diameter of the ball bearings and pulley I used. I tried various methods of creating a fit, but eventually landed on using a Dremel tool with a sanding mandrel. This worked wonders, and the result is more than adequate for the speed and loading of the bearings. I made an attempt at using the original plastic pipe as the main axle, along with a 3D printed coupler to an 8mm eye bolt. This worked, but there was too much slack in the system for proper belt tension. After the second dive trip the 3D printed part failed. In one of the pictures below the green coupler can be seen, inserted in the original plastic pipe for the main axle. For controlling the motor, I made a small RS-485 connected microcontroller board with an ATmega168. It's only function is to read the incoming control packets for the ROV, and interpret the Z axis control messages as motor control. In addition to this there are two momentary contact push buttons for manual motor control.
Umbilical Connection
As mentioned before, some kind of elastic connection is envisioned to dampen the effect of waves or other disturbances
from the surface. In addition, the ROV must be held at roughly 45 degrees in order to see the bottom, as the camera is mounted flush to the end cap. To solve this I designed a track for the umbilical to lie in, which could be pinched at the top to secure the umbilical cable. This provides a low-stress means of fastening the cable to the ROV. The ROV itself is suspended from two ropes connected to the strain relief unit. During casting of the umbilical connector, epoxy leaked through and fused the male and female ends together. Something to keep in mind if attempting the same with the Bulgin PX0739/P connectors.
I'm also somewhat uncertain how the umbilical-cable-to-ROV connection affects manoeuvrability of the ROV. I think the long ropes will mean the tether itself will almost never turn, whereas the ROV unit will spin easily to a point as the ropes will spin on themselves. After letting up the motors, I would assume the ROV would slowly spin back as it unwinds the long ropes. If the ROV was fastened directly to the tether cable instead, I think it would turn the entire cable up to the surface, which might not have the same need to unwind afterwards. Testing in the field seems to indicate that this is the case, but I'll need to try more to know for sure.
Video
Improvements and considerations
After using the acrylic plate version of the ROV in the field I'm not too satisfied with how hard it is to remove the front and back end caps. The back end cap is easy to pry off, but the front cap is very difficult to remove. There is little to hold on to, and the tube cannot be removed from the body until the front cap is removed... In addition to this the front cap is glued to the structure which holds the electronics tray, meaning it can't be angled during removal, which is precisely what is required to remove an end cap easily! For the next revision this is definitely something I'll try to design better. Related to this is using a different means of mounting the motors to the tube, perhaps using a 3D-printed clamp assembly.
The general size of the ROV unit and layout are somewhat excessive for it's function, which is essentially a drop camera. I've been considering the idea
of making a long tube with a single motor on one end to rotate the entire tube underwater. Place a camera and some lights on it, and it should serve as
a cheaper, smaller, and simpler device for viewing the ocean floor. However, as stated part of the idea was to use this ROV with a new floating tether unit.
The depth sensor mounting was problematic, and made finalizing the end cap a lot of tricky work. For the next iteration I recommend routing the wires required out the front, and looping them back to the depth sensor. That way the depth sensor can be assembled independently to the end cap.
For the motor control, I've seen integrated ESCs capable of controlling four different motors over more advanced protocols can be purchased. Typically
called a 4in1 module. This would have probably been cheaper and easier to integrate into the PCB than the three individual ESCs used.
I'm not entirely sure how the 3D printed parts will hold up, as even with 100% infill they are not entirely solid, but have small air pockets which will fill with water at the great pressures deep underwater. ABS printed parts should work OK, but I recently swapped to a PLA printer. If the parts I've printed out so far seem to last, I'll definitely print more components on my printer as it is cheaper, and the parts are much less brittle than acrylic plate. During the design process attempting to reduce the use of 3D printing by only using acrylic plates has been severely limiting.
The LED lights are no where near strong enough, and spill too much backlight into the camera. It took a lot of work to shadow away enough light that image quality wasn't destroyed by the excess light shining into the camera from all angles. I see underwater LED units can be purchased from various sources, so this might be something to consider. Otherwise making a new design where the LED is in contact with the ocean water for cooling, and with built-in temperature shutdown would be the next step forward. Using a proper reflector is also a strict requirement I believe.
Disclaimer:
I do not take responsibility for any injury, death, hurt ego, or other
forms of personal damage which may result from recreating these
experiments. Projects are merely presented as a source of inspiration,
and should only be conducted by responsible individuals, or under the
supervision of responsible individuals. It is your own life, so proceed
at your own risk! All projects are for noncommercial use only.
This work is licensed under a
Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
