Cylindrical ROV for polar research

Hi,

I am planning to construct an ROV using mostly BlueRobotics parts. I aim to keep it as simple as possible with only a camera and lights on the vessel. I may possibly want to add a DVL and IMU.

The ROV is being constructed to fit inside an ice borehole. The vessel can be no wider than a maximum of 30cm.

The vessel will thus have to be torpedo-shaped (like an AUV) and will be diving straight down through the hole and then get out on the other side of the hole where it needs to be somewhat stable in a horizontal position.

This is the first time I’m attempting to construct something like this. I have put together a BlueROV and operated a few different ROVs and AUVs before, but I expect there are lots of things I will need to learn during this project.

Please have a look at the design that I have so far and let me know if you have any ideas or if you see any direct issues with it.

Side view:

Top view:

Stability:

Ideally the vessel should be horizontally stable by adding weights to the bottom and buoyancy at the top. However, since the vessel needs to go vertically down through a borehole this stability will not be desirable during the dive phase. If the vessel isn’t stable enough, I’m worried that the aft thruster could cause it to start rolling. The suggested thruster setup has no way of counteracting a roll-issue. I could always put two thrusters in the aft with different spin-direction to counteract this, but it would be nice if I didn’t have to.

Thruster setup:

The aft thruster is a T500 and the rest are T200. Is there anything that I need to consider software-wise when mixing these thruster types?
I’ve been looking through the guides on how to create a custom thruster configuration and have altered the AP_Motors6DOF.cpp file to the following:

Thruster #1 is the aft one and then the rest are from front to back.

Lights:

I see a potential issue with the placement of the lights in my design due to high backscatter. Ideally, I would want them further out to the side, but this is of course not easy when I want to keep the vessel as slim as possible. I’ve been considering putting the light on an arm that can be extended once through the bore hole. But since I want to keep it as simple as possible, this is something I’d rather avoid.

I realise there aren’t any really clear questions in this post, but I guess I just want to pick your minds on the subject. I’m very much still at the beginning of the project so I assume I will update this thread as I go.

Cheers,
Filip

2 Likes

Hi @Filip, welcome to the forum! :slight_smile:

Sounds like an interesting project! :smiley:

As a starting point, I’d recommend browsing through the other posts with the vehicle-design tag, as there’s likely some relevant information and discussion there :slight_smile:

I expect this could be mitigated somewhat by including one or more rigid fins to help resist the undesirable rotation.

My first thought in that regard was a vertical fin just before and after the thruster to help direct the flow of water through the thruster, but I’m unsure whether that would negate or exacerbate the roll effect. It might be more useful to have fins further forward, away from the direct flow of the thruster, although that does then become harder to find space for without excessively increasing the outer diameter.

Given you’re using the different thruster types for control of independent motion axes, the type differences shouldn’t have an effect on the mixing.

From your thrust factors it looks like you’re expecting the vehicle’s centre of mass to be halfway between the thrusters (e.g. each thruster contributes equally to the rotational torque and/or sideways translation), which may be challenging in the current design given you have an enclosure at one end offset by only a thruster at the other end, and the pitch/yaw thrusters are spaced at roughly a third of the way from either side.

That may be possible to balance by adding some ballast weights, but moving that mass wastes energy if it’s not essential. If you reach a point where you can no longer redistribute mass and don’t want to add more then it’s possible to compensate in software by reducing the thrust contribution factors of the thrusters that are further away from the centre of mass, but this does reduce the total force-generating capacity of the vehicle for that motion axis.

That said, if you already plan to limit the maximum thrust of those thrusters for power supply current-capacity reasons, then such software compensation could be a net benefit, and help to reduce some design challenges.

Depending on your operating conditions, it might help to point the lights outwards, rather than inwards?

Fair enough for wanting to avoid this complexity, although integration-wise it could be quite simple (just adding a servo control that extends the arm) - the main challenges would be around the mechanical design, water-suitability of the materials, and potentially the servo depth rating (depending on your requirements).

Great to hear - I’m keen to see how this progresses over time, and it may be able to serve as a reference for others looking to make their own custom designs :slight_smile:

By the way, please feel free to make note of any times you struggle to find information you’re after. Documentation can always be improved, and while there are areas we’re already aware of that could use some love, there are certainly also areas we just haven’t realised are missing things or in need of improvement.

Hi @Filip -
Just a note on your single T500 for forward propulsion. It will create a torque as you say, and if not balancing out with a counter-rotating propeller, you could also “de-spin” by using geometry in front of or behind the thruster that will twist the water the opposite direction from the propellers rotation. This will have a large drag impact, but should keep you from barrel-rolling quite as much!

@EliotBR , thank you so much for your elaborate reply!

Now I have several improvemens that I can consider before starting putting together a first prototype.

To be honest I had not given much thought into the thrust factors.
However, I think limiting the maximum thrust will not be an issue so this could very well be a valid path to take.

It’s great to hear that you don’t think adding an extendable arm would be much trouble. I will keep this in mind as the project progresses (though it may be something that I add at a later iteration).

@tony-white , thank you for this suggestion. Hopefully a combination of this along with the fins Eliot mentioned could be enough to mitigate the roll.

@EliotBR, I was following this page in order to setup the ArduSub repository from github. This seemed to work as it should, but then I found this post. Here, you mention that it’s preferrable to clone the repository from your own github and not the official ardupilot project. I went ahead and made a fork from the ardupilot/ardupilot project unto my own github and cloned from there. Now I get the following error:

$ git checkout ArduSub-stable
error: pathspec ‘ArduSub-stable’ did not match any file(s) known to git

Any ideas as to what may be causing this?
I’ve since tried removing the repository and cloning from ardupilot/ardupilot again and I am then able to checkout with no errors:

$ git checkout ArduSub-stable -b new-branch
Updating files: 100% (5123/5123), done.
Switched to a new branch ‘new-branch’

Hi!
Stabiity idea:
Have a weight that is movable (by threads?) inside.
Then you can have neutral balance going threw ice, and move the weight(s) to bottom part when below ice.

Also by attaching the tether far to the rear you might get the ROV back into the icetunnel by pulling.

1 Like

Hi Bo,

The moving weight idea is something I have considered, so I’m glad to hear somebody else mention it as well. Do you know if it has been successful on other ROVs?

When I was thinking about the weight I was however thinking of having one that moves to make the vessel nose heavy for the dive part and then move to make it horizonally stable once through the ice. But if I understand you correctly, you’d have it move so that it’s neutral for the dive phase? This sounds like it might be better than my original plan, both with regards to behaviour and you wouldn’t have to move the weight as far.

The tether at the back is also where I thought I’d put it. I’ve also considered putting a second camera at the back to use when going back to the hole.

Hi again!
Stability/LARS:
Thinking more I would go for a more simple solution, aka KISS
Have a standard static balance by low center of gravity running the ROV.
To solve the LARS solution through ice I would test to have a tether point behind the thruster. Then it might be possible to recover even a dead ROV.
Yellow line in picture is top bar with tether point.
You might need two bars on the bottom side as well to steer into the icehole.
(the two red lines)

For testing I would get a tube/pipe with the same diameter as the icehole.
Then it is possible to test LARS in a pool, at a jetty or whereever.

Rotation from single thruster:
It might work with just one thruster, depending on weight balance and power used, try and error.
If it is a problem try two counter rotating thrusters in a row.
That is well proven for torpedos and boats

1 Like

Did you remember to git fetch --tags before trying to checkout the tag?

Hi @EliotBR,

Thanks for taking the time to assist me with this.
I did run git fetch --tags for both clones.

I mentioned that it worked well when I cloned from the official github, but when I continue with this i run into a new error on the next step of the guide:

$ Tools/environment_install/install-prereqs-ubuntu.sh -y
---------- Tools/environment_install/install-prereqs-ubuntu.sh start ----------
‘[’ 197610 == 0 ‘]’
OPT=/opt
ARDUPILOT_TOOLS=Tools/autotest
ASSUME_YES=false
QUIET=false
sep=‘##############################################’
OPTIND=1
getopts yq opt
case “$opt” in
ASSUME_YES=true
getopts yq opt
APT_GET=‘sudo apt-get’
true
APT_GET=‘sudo apt-get --assume-yes’
false
sudo apt-get --assume-yes update
Tools/environment_install/install-prereqs-ubuntu.sh: line 41: sudo: command not found

I also get this error when trying to check on waf:

$ ./waf --help
Traceback (most recent call last):
File “C:\Users\Filip\ardupilot\modules\waf\waf-light”, line 166, in
from waflib import Scripting
File “C:\Users\Filip\ardupilot\modules\waf\waflib\Scripting.py”, line 10, in
from waflib import Utils, Configure, Logs, Options, ConfigSet, Context, Errors, Build, Node
File “C:\Users\Filip\ardupilot\modules\waf\waflib\Configure.py”, line 16, in
from waflib import ConfigSet, Utils, Options, Logs, Context, Build, Errors
File “C:\Users\Filip\ardupilot\modules\waf\waflib\Options.py”, line 14, in
from waflib import Logs, Utils, Context, Errors
File “C:\Users\Filip\ardupilot\modules\waf\waflib\Context.py”, line 9, in
import os, re, imp, sys
ModuleNotFoundError: No module named ‘imp’

So I’m guessing there’s some issue even when cloning from the official ardupilot github.

Cheers,
Filip