Hi, I’m currently studying subsea inspection systems for constrained coastal environments.
I’d like to better understand real-world limitations of ArduSub in:
low visibility conditions
current-heavy environments
sensor reliability in turbid water
If this is not the right place, I’d really appreciate being pointed in the right direction.
Thanks a lot.
Hi @ALBlue, welcome to the forum 
This is a challenge for manual operation (especially without some kind of sonar-based support), and for visual positioning techniques, but both of those are at a level before what ArduSub deals with, so are more impactful to the practicalities of operating a vehicle than they are to the vehicle firmware and its control algorithms.
The main limitations here are power supply capacity and thrust capacity, which are both hardware concerns. ArduSub provides depth and attitude stabilisation control modes, and (with appropriate, often acoustic, positioning sensors installed) can maintain a position or follow an autonomous mission, but all of those are reliant on the physical capabilities of the hardware. If the vehicle doesn’t have enough thrust then as much as the control systems might say “we need to push harder”, the vehicle will still get washed away from its goal.
This is primarily an issue for visual sensors like cameras - especially because shining extra light to try to see further generally just results in backscatter that overexposes the camera instead. Again, this is more of an operator concern than one for the autopilot firmware.
Turbidity is irrelevant to the inertial sensors in a flight controller, and also generally has limited effect on sonar-based visioning, positioning, and range-finding sensors, though that can depend on its nature (e.g. air bubbles have a substantial impact on sonar range/visibility).
Thanks a lot for the detailed breakdown — this is extremely helpful.
What stands out to me is that the main limitations are not coming from the control stack itself, but rather from environmental constraints and hardware capabilities.
In particular:
This aligns quite closely with what we’re exploring: shifting away from vision-dependent operations toward sonar-driven perception and more robust navigation stacks.
I’d be very interested to understand, from your experience:
Really appreciate your insights — this is extremely valuable for shaping our system design.
That’s entirely dependent on the operating conditions, and the estimation of how they’re likely to be in advance.
For what purpose? A barometer for depth estimation may be largely unaffected, while an acoustic positioning system may work reasonably well, etc.
This is dependent on the vehicle’s thrust capacity and power supply capacity, and also its drag area in the direction of current. You can design a vehicle to handle a particular current speed, but there’s no magic number that’s inherent to vehicles in general, and ability to resist current is also time dependent (e.g. power output relates to peak velocity, whereas energy storage relates to sustained performance).
Hi, Eliot
Thank you — this is extremely insightful.
One thing I find particularly interesting in your answers is that the limiting factor seems less related to a single technology, and more to the vehicle’s overall ability to maintain reliable mission performance under degraded environmental conditions.
I’d really love to better understand the operational reality behind that.
From your experience:
In highly turbid environments, which sensing modalities remain genuinely usable in practice over long missions?
What typically becomes the first operational bottleneck:
perception,
localization,
station-keeping,
operator workload,
or energy consumption?
Are there specific current ranges or turbulence conditions where operators start considering missions “high risk” or economically inefficient?
In practice, how much does vehicle hydrodynamics impact station-keeping compared to raw thrust power?
Have you seen acoustic-relative navigation or sonar-based perception significantly outperform vision-based approaches in difficult environments
When missions fail or are aborted, what are usually the root causes?
I’m currently researching robust underwater navigation/perception architectures for degraded-visibility operations, so even high-level operational feedback is incredibly valuable.
Thanks again for taking the time to share your experience.
Best regards,
Hi @ALBlue -
My two cents, staying within the ROV context -
If you can’t see, sonar is all that is really left! A multibeam imaging sonar can give you a video-like picture of your surroundings, or a scanning sonar like the Ping360 or Sonoptix FS can provide less frequent updates that let you orient the position of the vehicle to external objects. Have you seen this resource? A DVL gives relative velocity, good for position hold, but if you need absolute position, a USBL can augment or be used stand-alone (WaterLinked underwater GPS or Cerulean Omnitrack.) For any of those approaches, the increase in power consumption is fairly negligible.
Thinking of a typical “mission to the bottom”, conditions like currents and winds dictate how easy the operation will be. If you’re able to run the ROV from shore or a moored boat, that is much easier than “live-boating”, which requires at least 3 people (ROV operator, Captain, tether handler.)
If the vehicle can overcome the tether drag at the surface, that doesn’t mean it will continue to do so as it descends - currents can increase, and as more tether is put out, more drag needs to be overcome. The turn-around point is dictated by battery voltage, much like a scuba diver reaching half-tank, there comes a point where recovery needs to start.
I wouldn’t consider turbulence an issue in most circumstances, but if water current speeds are too high, its often not worth attempting. If seas are rough and you’re on a small boat, a lot comes down to how stern a stomach your ROV pilot has.
A more hydrodynamic vehicle uses less power to overcome currents. Regardless of how hydrodynamic you are, if you can’t push more sufficient water to overcome vehicle + tether drag, you’re not going far!
Yes! I’ve watched an ROV pilot explore a plane wreck via sonar alone, when a prototype camera was damaged and they still wanted to check it out.
Tether not long enough, conditions not suitable, no more charged batteries available. On extremely rare cases (at least in the age of the WetLink Penetrator vs. potting), leaks can lead to aborting a deployment.
Hi Tony,
Thank you again for your insights — they’ve been extremely valuable.
One thing that really stands out to me is that the main challenge in difficult underwater environments seems to be less about a single sensor or technology, and more about maintaining reliable overall mission performance despite uncertainty, degraded visibility, turbulence, and operator constraints.
I’d really like to better understand where the real operational limits appear in practice.
From your experience:
In difficult environments, what usually degrades first during a mission?
vehicle perception,
localization accuracy,
station-keeping,
operator situational awareness,
tether management,
or energy endurance?
Are there specific visibility or current conditions where missions become technically possible, but operationally inefficient or too risky to justify economically?
Which sensing systems remain genuinely dependable during long operations in highly turbid water?
For example:
imaging sonar,
DVL,
acoustic positioning,
inertial navigation,
optical systems,
etc.
In practice, how much of effective station-keeping comes from:
raw thrust power,
versus vehicle hydrodynamics and passive stability?
Have you seen situations where sonar/acoustic-relative navigation clearly outperformed vision-based workflows in real operations?
When missions are aborted, what are the most common root causes operational teams encounter?
Finally, are there operational pain points that current ROV/AUV systems still handle poorly today, especially in low-visibility or high-current environments?
I’m currently researching architectures focused on robust degraded-environment underwater operations, so practical field feedback like this is incredibly useful and difficult to find publicly.
Thank you again for taking the time to share your experience.
Best regards,
Ludovic André
Hi @ALBlue -
Your response seems a bit repetitive - are you using a LLM to translate? Just wondering if you’re “real” 
Yes I am french and using a translator.
That and the fact that I am just getting started on this project may make it seem like I am not real, but I am