Best way to determine distance between multiple BlueROV's?

I’ve been looking at ways to do this and would appreciate thoughts and feedback.

One way is using the “underwater GPS”, but that relies on a centralized array of receivers. I’d like each ROV to be able to determine how far each other ROV is, in a distributed manner. Direction is less important, so I may not need the multiple receivers in a USBL configuration - but each should be able to transmit and receive, and communicate it’s “unique ID”.

The Wikipedia page “Underwater acoustic positioning system” shows an example called NetTrack that should perfectly fit my plan, but I have no concrete thoughts on how to do this with lower cost off-the-shelf components.

2 Likes

Interesting idea!

If you want it to be direction agnostic then you’ll need to transmit in all directions and receive from all directions, which would likely get expensive quite fast. Also relevant are vertical directionality and maximum distance.

If they’re all basically on a horizontal plane and within ~50m of each other, you could maybe get away with something like a single ping360 sonar on top of each ROV and some custom firmware that can do individual receives and transmits. To achieve that you’d need a centralised controller like in NetTrack, where it tells all of them “X is now transmitting”, and if you are X you then do a transmit sweep while the others do a receive sweep, until the receivers have all locked onto the direction to the transmitter, then the controller could get X to transmit in the direction of each ROV one at a time, and time how long it takes from the send command to when the signal is received. Seems like it would be relatively slow to do something like that, but if the general direction is known it the receive sweeps could be in quite a small angle range of uncertainty.

Additionally, because directionality is known you could do only one measurement per ROV if desired (to speed things up) and you’d have a network graph specifying where each is and which one is closest to it. Alternatively you could do all the possible measurements and get an estimate of error, as they did in NetTrack. There’s also the option to do something like MiloNet where ones that are close enough do measurements to each other, but if one is only close enough to one of the others (ie it’s on the edge of the network) then you can still get an estimate of distance, which massively extends the total range you can cover as long as you have ROVs spaced within their maximum detection distance (e.g. you could have a long line, or cross (+) configuration going like 200m out from the center and still tracking distances.

Unfortunately this idea is quite reliant on relative horizontal position, although thanks to the 25 degree vertical beam height of the ping360 you could have relatively significant depth differences for far apart ROVs, and integrate each ROV’s depth measurements to help determine which ROV you’d need to use to communicate. Oh also ping360 is rated to 50m of return signal, so maybe the detectable range would be greater for a single direction…

In case you haven’t noticed, I’ve gotten more excited about this as I’ve been writing… :stuck_out_tongue:

1 Like

At what distance and depth does it need to be implemented?

We once put three ROV into water at the same time. There will be off-line signal interference if these buoyancy cable is too near and winding.
There’s an interesting thing later, we found that if the PLC cable was cut off without line connection, the signal transmission could be completed as long as the wiring was close enough.(The cables are not welded but placed parallel very close).

Thanks, the custom firmware part is interesting and also got me down a rabbit hole. To remove the need for a centralized controller (it seems kind of redundant having one system for control, the other for ranging), I could consider custom symbols to identify each rover. It would be a wicked problem trying to separate out all the responses from each other - and each would need a minimum of 2 receivers in an array to isolate signals by location. (Could be actually cheaper to have atomic clocks at ~$300 each and only doing one way!) At this point it probably is best to just have co-ordination with a centralized controller though.

Not more than 200m. I’m also assuming as each would know it’s own depth, it could possibly use or communicate that to others to help in “ded-reckoning” on figuring out 3d location with incomplete information from pings alone.