Home        Store        Learn        Blog

Unfinished ROV Dream

In 2008, I was sitting at a local lake watching divers searching for the body of a missing teacher. I thought to myself there has got to be an easier way to do something like that, so I went to work designing my own ROV. In 2009 I began Construction. I was in the engineering program in college, I was going to use this for my senior project. In 2010 I was in a terrible car accident, which led to dropping out of college. The project ended up getting put on hold and eventually put into storage.I went to work as a truck driver, and between work and family lost all time to be able to work on the project. This has been a dream that I want him to complete it for a long time. Recently I have started searching the Internet for ideas, and have noticed technology in this field has grown by leaps and bounds. I am looking for suggestions, ideas, advice, tips and tricks, and any other help, that would help me finish my dream.


Here are some more photos, everything has been machined by hand. And as you can tell most of the internal electronic components are outdated. The batteries are 12 V gel, and purchased before Lipo became affordable.

Welcome to the community Jason!

You’ve got a really inspirational story, and it’s great that you’re back into looking into your project.

The progress you’ve made is commendable. I particularly like the machined motor casings - they look amazing!

This is quite possibly the best place to come for this, so I really hope this community can come together and help you out. For you to get the most out of it, would you be able to share a bit more about the system you’ve got so far (what it can do, how it’s controlled, etc), as well as what you’re hoping to get help with? I’m not sure how much of your existing system you’re wanting to continue using, and what kind of scope you’re currently aiming for with regards to the end product.

As an example, relevant advice for personally creating one unit that can help with finding bodies underwater would be quite different to if you’re wanting building up an optimised system that’s tailored to the task, which could end with a sellable product that could be distributed around the world. You might also want to consider things like the development of a computer vision algorithm that can detect bodies or high-priority inspection locations in an underwater environment, possibly even autonomously controlled.

In the meantime, I’d recommend having a look at the components available in the Blue Robotics store for a sense of the types of components that are now available, and it might help to look at the websites of some distributors to see a bit more of what’s broadly ‘out there’. Once you’ve clarified a bit more about what you’re after we can no doubt help you to find relevant products where they exist, and provide suggestions for what types of things you might need or be interested in once we know the scope you’re working on :slight_smile:

Thank you for your response. So I guess I’ll start with the control system, and go through my follies so those just getting into this field can learn from my mistakes, and for the more experienced can have a good laugh. When I first started trying to figure out how to control it, all I knew about electronica control is what I had learned from flying RC airplanes and helicopters. So yep, you guessed it, I tried to build an ROV and use radio control. I soon found out that that only works it just a couple feet of water before the water surface reflects too much of the radio signal. Back to the drawing board. Next I got some cat5 wire and some servo plugs, and wired it so that the receiver would stay on the surface. It worked, but only with about 15 feet of tether When I tried with 200 feet of tether, too much of the timing signal was lost to control the speed controllers and servos correctly. Back to the drawing board. Next, I got 200 feet of small diameter coax, which shielding. Tore into the back of my Futuna radio, and soldered it in where the antenna went, learned a little about antenna theory and the exact amount that I would need to expose on the other end of the coax and ran it to the ROV. Now this work, and I was getting somewhere, but with several drawbacks. 1. Fly by stick only 2. No way to receive data or signal from sensors. 3. Trims could not be adjusted precise enough to keep from rolling or yawing. 4. Signal interference from camera coax causing it to act sporadically. End result, just a really expensive pool toy :-1:t2:. I tried also using a couple Parallax basic stamp microcontrollers, an old flight sim controller, and the cat5 wire and wrote the code. I still ran into a lot of the same problems though with this approach. Keep in mind before you criticize, that I was dealing with basic technology from the late 90s and early 2000s. When I was trying to do all this, the basic stuff that is available today that is affordable, had not even been thought of yet. So with all that said, I have recently started looking at ArduSub. It looks like a good system With expansion capabilities, and, is kind of what I had envisioned being able to do years and years ago. Is there any other systems that I should maybe look at, or do you have any opinion on pros And cons of ArduSub?

Not planning to criticise. You were working without access to an open community of other individuals and companies, and singlehandedly solving several of the more challenging aspects of underwater electronics!

I haven’t personally worked with systems outside of ArduSub, so can’t help much on that front. In terms of how viable it’s likely to be for your use case, perhaps it’s easiest to describe what ArduSub does (and doesn’t) do, and how the Blue Robotics’ approach is set up to handle several (but not all) of the issues facing ROVs.


ArduSub is a ‘flight controller’ software, and is made to solve the problem of “I want the ROV to move like this” → “ROV actually moves like that”. It operates using the mavlink protocol, which allows the device running ArduSub to receive commands on what to do, and also send back status updates of telemetry data (e.g. speed, temperature, depth, GPS position, etc, depending on the connected sensors). The commands used can be manual control commands (‘fly by stick’), or, with a connected GPS or other positioning system, can be based on waypoints (‘go to this location’), from which ArduSub controls the ROV thrusters and other connected actuators (e.g. a gripper). There are additional operation modes for stability, including things like depth/position holding. A lot more information is available in the documentation.

Command Source

ArduSub running on suitable hardware can convert mavlink messages into meaningful ROV movement/actuation, but those messages still need to come from somewhere. The options there are effectively limited to a computer in the ROV, or a person controlling the ROV from a computer that can communicate with it. Autonomous systems don’t necessarily require a communication link to the surface at all if they’re programmed beforehand with a path or objective, but no link means no updates until it returns.

The BlueROV2 approach is to use manual tethered control from the top, which allows commands to be sent down the tether, and the ROV operator can receive telemetry data and video streams in real time. To achieve this, a Fathom-X board is used on either end of the CAT-5 tether to basically step up the voltage and convert to an AC signal so that the ethernet signal sent over the tether can reach the other end without significant losses from electrical resistance. Within the ROV there’s a Raspberry Pi ‘companion computer’, which handles converting between mavlink and ethernet, basically acting as a bridge between the Pixhawk running ArduSub and the control computer running something like QGroundControl (control software on the operator’s compute that uses mavlink to communicate). Since the Raspberry Pi is an actual computer, it’s also used in the BlueROV2 for connecting to a camera and streaming it up to the top computer, as well as providing a locally-hosted web interface to modify camera properties, measure connection bandwidth, update firmware, and other convenient things.

There are also other communication methods, such as fibre-optic tether which has a very high bandwidth and extremely long operating distance but is generally quite expensive, and in theory it’s possible to do wireless communication with sound waves but the bandwidth would be very low, and it’s technologically very challenging to do in a practical/usable way.


The whole BlueROV system is designed to be modular, and accordingly is very expandable although sometimes with some difficulty.

ArduSub has a consistent PWM output interface, which means any actuator which can use that interface can basically just be plugged into some power and an available Pixhawk autopilot board output port and then it can be controlled with QGroundControl. Products such as the Blue Robotics lights and gripper are then ‘plug and play’, which is very convenient.

Having a versatile companion computer like the Raspberry Pi on-board means it’s also possible to add extra cameras, and non-standard sensors (ones that aren’t supported already by ArduSub), and with a bit of code they can be up and running, and it’s even possible to send readings to the top as mavlink messages so they end up as part of the same data stream as the normal telemetry data. Blue Robotics designs some sensors that are supported by default (in particular the ping360 scanning sonar and the ping altimeter), and these will automatically connect if they get plugged into a computer running the Blue Robotics companion software.


Like any system or product, the BlueROV2 way of doing things isn’t optimised for every possible scenario. It’s designed to provide a good base platform for others to work off, so it’s a very capable machine and easy to get started with, but if you have a very specific purpose in mind then you’ll likely need to make some modifications to achieve that.

In particular, tethered operation can be problematic if you’re working in very tight spaces, or weaving between dock pilings or rocks and similar. In those cases it might be preferable to have an autonomous ROV, but it’s then important to note the lack of possible communication with the ROV during dives, and the added risk of it getting lost.

While the system Blue Robotics has set up is intended to be expandable, there’s a limit on how much development their engineers can do ahead of time, so to do something like add several extra cameras isn’t quite as simple as plug in and adjust a couple of settings, and the resulting interface at the end can involve a bit of mixing and matching between different programs to be able to see all the things you want to. In saying that, the products Blue Robotics does make and support are generally very well priced within the market, as well as being high quality and well supported. In addition, when you’re wanting to do something special or out of the ordinary there’s a great community here to help :slight_smile:

Hope that’s useful as a starting point/introduction. As I mentioned earlier there are several experienced community members about if you want help, and also a variety of distributors who might have a product that fills a functionality gap for your use-case.


IMO, Ardusub is the best thing going for ‘flying’ the ROV, but lacks expansion for anything but a few lights and a primitive gripper.

But since you have a Raspberry Pi in the ROV, it can be connected to an Arduino (which has lots more PWM outputs than the R Pi). Use something like FlowArm from Lynxmotion Lynxmotion - Software running on the topside PC to control servos, lights, and manipulators below.

If you can butcher a common security-system DVR, fit the board into the ROV water-tight-container (WTC), you can connect it to a 4-port hub, then thru the fathom x ethernet link topside. Attach up to 8 epoxy-encapsulated FPV cameras, sign into the DVR’s browser address, and view 8 camera feeds in realtime.

The bigger/heavier you build the ROV, the less tether drag and current affect it. My new design is the size of a chest freezer, with a tether-management drop cage. Custom-built Li-ion battery packs. Batteries sourced from batteryhookup.com, bms’s from eBay.

You seem to be a creative thinker. Think outside the box.

Hi Jason,

I just wanted to reach out and ask if it would be okay to share your project on our socials?! Everyone at Blue Robotics is loving it and we think our community would as well!

Thank you!


KristeI would be honored if you shared my project. Although still a work in progress, it is a good feeling to know others like and are impressed by the work I’ve accomplished so far. Thank you for reaching out.