OpenROV Testing at Hall City Cave

Robotics
OpenROV Testing at Hall City Cave

As was previously reported here on MAKE, recently, a group of us OpenROVers journeyed to Hall City Cave just outside of Wildwood, CA. The goal of the trip was to do a shakedown of ourselves and the ROV in the field, and as a mission, determine if (inside the underwater cave) the vertical cave shaft connects with the 45 degree sloped shaft. The cave was the original inspiration for Eric to begin creating an ROV, and has since evolved into the open source project that it is today.

Needless to say, we had quite an adventure – driving through heavy snow, trekking along mountain paths with robots and tool boxes, landing single engine planes on snow covered runways. We’re still digesting much of what happened and we’ll be writing up a longer report of the adventure soon, but we wanted to give a quick update on how the robot worked!

When it comes to small ROV design, there are three general fields that always seem to require the most development:

  • Onboard electronics/embedded system design
  • Communication and power through a tether
  • Water and Pressure proofing


Embedded Systems
Background (and what we’ve been doing so far):
OpenROV is being developed as a platform that can support scientific research and tech development. In order to be as effective as possible at this, we’ve been doing lots of research on how to get a small computer, such as an Android phone, BeagleBone, or the upcoming Raspberry Pi to host video, monitor sensors, and control thrusters while communicating to the surface. Bran Sorem has been developing some code for embedded Linux which could be run on these devises and has also been working on a GUI interface that will make OpenROV intuitive and satisfying to operate.

Enter Bran…

I’ve been working on the software for OpenROV and believe we have mostly established a good base for future development. We are currently using a BeagleBone as the primary onboard computer (though we plan to move to the Raspberry Pi once that’s feasible) with an off-the-shelf webcam attached. The goal of the software is to provide an easy-to-use and simple-to-extend, yet powerful, framework for operating the vehicle. For that, we are using Ubuntu Linux as the operating system with NodeJS on top to serve a webpage that allows the ROV to be controlled from any modern web browser.

Video is handled by a simple OpenCV program that captures frames and saves them as JPG’s, which Socket.IO then sends to the controlling browser. Having support for OpenCV greatly opens the opportunity for development of more advanced applications (such as tracking fish). Socket.IO allows for full-duplex communication – which will handle the video updates as well as directional control of the ROV.

So far, I’ve been working to get a live video feed working but have run into a stumbling block (mostly the fact that I’m learning NodeJS and OpenCV as I go). The OpenCV program accepts a folder (the current date) as an argument then waits for stdin: each line of input is a file name (current time) to save the image as, which the program then uses to grab a frame from the webcam and save. This will occur continuously until the connection is broken. The problem right now is in the NodeJS application – it seems to be spitting out the correct filenames, but I’m trying to pipe the process.stdout to the child.stdin and having trouble. Any help or advice would be GREATLY appreciated.

There is a lot more to come in the future, but first we want to get the video working. The code will be hosted on Github.

For our resent trip, development had not gotten us to the point where we could control the ROV with an onboard computer, so instead we just used an RC controller which talked to the receiver on the ROV through a long wire which effectively ducted the RF through the water.

How you can help:
What do you think? Have you done any embedded systems work with a BeagleBone? Any ideas for transferring live video over an Ethernet connection (that can also fit in our water-tight cylinder?

Tethers
Background (What we’ve been doing so far):
Tethers are often the most challenging part of an ROV to develop because they must be able to communicate large amounts of data and power while still remaining agile enough to allow the ROV to move easily through the water, and they must be either neutrally buoyant or light enough to not drag the ROV down as more and more of it is payed out into the water. Especially for small ROVs like OpenROV 2.2, the best solution is to make the tether thin and light weight enough that buoyancy compensation is not needed.

For the Hall City Cave trip, we used a twisted pair of 28AWG stranded wire, and it seemed to work very well- if we had been using thicker tether such as Ethernet, the ROV would have had a much harder time moving around, and the weight of the tether would have made it hard for the ROV to maintain a given depth. We’d like to continue using very thin tethers such as this one (or perhaps extremely thin coax such as RG-178), but the challenge we’re facing is how to send high bandwidth data through it.

There are several approaches to this. For starters, you could go analog and use a video balun to send images from an RCA-output camera up from the ROV while allowing RF signals from an RC transmitter to pass down the tether. Or, you might be able to use one of these fancy devises to convert double twisted pair Ethernet to single twisted pair.
Finally, you could just use a data over powerline system (as discussed here).

How you can help:
These are some of the ideas we’ve thought of, but we’d love to see some other thoughts on how do do this. (Remember once again, all the ROV-side equpment for this has to fit in a 90mm ID by 150mm long tube!)

Waterproofing
Background (What we’ve been doing so far):
For waterproofing the electronics, we’ve had great success with our cylindrical housing and laser-cut acrylic endcaps. We’ve been potting the pass-throughs with epoxy. The brushless motors have received a coating of marine-grade resin to prevent oxidizing.

How you can help:
The method has worked so far, but it’s ripe for an easier and less time-intensive process. Let us know if you have any ideas for potting or motor waterproofing.

BONUS: Add-ons!
Background (What we’ve been doing so far):
One of OpenROV 2.2’s greatest features is it’s payload module bay. We’ve put mounting holes in the bottom of the shell of the ROV for up to four M5 threaded rods, each spaced 50mm apart. The purpose of this is so you can make your own payloads (such as robot arms, metal detectors, chemical sensors, etc) which can mount easily to the bottom of the ROV. The width of these payloads can be up to 135mm or 200mm if the on board battery packs are removed.

How you can help:
We’re always looking for ways to improve OpenROV, and having a community of people thinking about it is the best way to get new innovation and different perspectives. After all, that’s what Open Hardware is all about!

Feel free to check out the OpenROV forums for some of the other strategies we’ve checked out. Also, let us know if you’ve got any other adventure ideas!

More:
Read David Lang’s Zero to Maker column here on MAKE

What will the next generation of Make: look like? We’re inviting you to shape the future by investing in Make:. By becoming an investor, you help decide what’s next. The future of Make: is in your hands. Learn More.

Tagged

Gareth Branwyn is a freelance writer and the former Editorial Director of Maker Media. He is the author or editor of over a dozen books on technology, DIY, and geek culture. He is currently a contributor to Boing Boing, Wink Books, and Wink Fun. His free weekly-ish maker tips newsletter can be found at garstipsandtools.com.

View more articles by Gareth Branwyn
Discuss this article with the rest of the community on our Discord server!

ADVERTISEMENT

Escape to an island of imagination + innovation as Maker Faire Bay Area returns for its 16th iteration!

Prices Increase in....

Days
Hours
Minutes
Seconds
FEEDBACK