So as I begin my journey with ROVs I have to ask why are USBL positioning systems so expensive? Surely it’s not component cost? The theory seems straightforward for crude and basic positioning. I can see the challenges with filtering reflections but even this seems doable. Can someone rightly school me as to why these systems start around $4000 US and skyrocket upwards? I’m sure there are obvious reasons but I just haven’t come across them yet in my literature searches.
This isn’t something I’ve looked into in depth, but at a guess I’d assume the main causes are
- low volumes
- manufacturing of custom components (e.g. transducers, housings, etc) is expensive
- amortisation (spreading/averaging) of development costs is done over a small sample size, so contributes more to the cost of each purchase
- traditionally mostly used in high-budget high-requirement industries (e.g. military, oil&gas)
- significant depth ratings and high precision and accuracy requirements are expensive, and if that’s the primary market then volumes stay too low to start a feedback loop where costs decrease and demand increases (although that’s now definitely underway)
- low competition
- while the space is definitely heating up as consumer level ROVs and the like become more popular, that’s a reasonably recent phenomenon so there aren’t yet many companies involved in designing and producing positioning systems for that market
- alternative solutions with similar accuracy are also expensive, which reduces motivation for significantly lower prices
- vehicle incompatibility
- the existing vehicles on the market often have different ways of handling data, so developing a positioning system that’s actually usable by the addressable market also requires creating integrations for a variety of vehicle types, which may already have a positioning system they don’t want to undercut, or may not be designed to handle one at all
- with an open-source and modular system like ours that kind of integration is intended to be relatively straightforward, and we’re also planning to make it easier via BlueOS, but that still requires technical and software know-how
- most other systems would be more involved to create and share an integration for, and for pre-made systems the design company may refuse to allow it / provide the required information to make it possible
- setup requirements
- while underwater positioning is definitely useful, suitable external setup for USBLs is not always feasible for commercial requirements (e.g. infrastructure inspections may have too many obstacles), and may be too much hassle for many consumer dives (just want to explore a bit)
- external setup can be expensive in itself, which may reduce demand for the product
- low “public” accessibility of underwater sonar technology
- while the concepts themselves have been researched and written about, there aren’t yet affordable and accessible options for hobbyists and the like to try out and tinker with, so it’s hard for people to start development without potentially significant upfront costs and learning
I expect costs of various underwater positioning systems should continue decreasing, but at this point we’re not far enough down the curve for them to be readily affordable for whoever wants a play. For businesses where they’re essential, if they have sufficient work then the existing offerings are already affordable and in use, whereas applications that require cheaper options and can perhaps handle lower precision are either using a different approach (e.g. navigating more manually with camera feed, scanning sonar, etc), or are being handled by divers or just not being done at all.
Perhaps others can chime in with any significant considerations that I’ve missed
Holy Cow Eliot! That’s an amazingly in-depth and super quick response. Its almost like you had this list already written up and were waiting to push the trigger I’m super impressed.
I suspected low volume and specialty markets like oil&gas and military no doubt have elevated the costs for a market where precision is crucial. I also get the manufacturing of custom components. We make a lot of components in-house and they are time consuming to say the least. I’m always looking for ways to automate and increase our efficiency. We used to outsource a lot more but have figured out ways to cut out the intermediary supplier and have greatly reduced our own costs. I hope this same scenario continues in this market. Honestly, I’m surprised more serious hobbyists/diy’ers/makers haven’t delved head long into this challenge. Kind of exciting really. Once I get some of my own projects out of the way I’d love to play around with this. The nanomodems posted on these forums see like a great way to start for not too much of an investment. I think medium accuracy would be highly desirable by many if it meant significantly cheaper costs.
Haha, nope, just too much stuck in my head. Thanks for asking the question - now that it’s written down I can stop thinking as much about those things, and just provide a link to the discussion here if/when it comes up again
Definitely exciting times, and agreed on the lower accuracy requirements for more widespread use (i.e. “cheap something” is in many cases better than both “nothing” and “expensive everything”)
Sonar development becoming more accessible is very much aligned with our mission, and is something we’ve thought about and discussed internally. At this stage that’s relegated to longer term plans on our part though, since our development resources are unfortunately finite…
@Willemb We may be able to help you. We have positioning systems that may fit your budget. Our ROV Locator start at $1,995.00 with the top of the line at $4,105.
Mk II baseline. This is the lowest cost and requires some operator interaction to synchronize the timebases in the transmitter and receiver to provide accurate slant range. This typically requires about 15 seconds of operator time at the mission start and periodically (every hour or two) during the mission. The baseline unit allows for multiple receivers to pair simultaneously with one transmitter.
Mk II Autosync. This costs a bit more than a baseline unit, and automatically synchronizes the timebases using GPS or GNSS. Synchronization requires both the transmitter and receiver to be independently exposed to GPS/GNSS signals at the start of the mission and periodically (every hour or two) during the mission. Additionally, Mk II autosync units can operate on either of two channels allowing two independent ROVs in the same operating area. The autosync unit allows for multiple receivers to pair simultaneously with one transmitter on each channel.
Mk III. This is the most expensive of the three systems. The transceiver sends an interrogation pulse to the transponder, which returns an answer pulse. Slant range is calculated from time of flight, so no timebase synchronization is needed and thus the system can remain submerged indefinitely. Only one Mk III pair can operate in an area at one time.
ROVL Mk II: Sonar: ROV Locator Bundle Mark II – ceruleansonar
ROVL Mk III: ROV Locator Bundle Mark III – ceruleansonar
Let us know if you have any questions,
Take a look at Cerulean, we are having really good results with the ROVL. The two channel option on the MK II is great for improving accuracy and differential heading.
That’s good to hear. I did get a reply from Dennys. From what I’ve read there is less hassle with the Mk III as there is less calibration to do. We are hoping to use this in a project that would require daily surveying for at least a month. The Mk III price was a lot more than the Mark II. For a daily grind like we’re going to do would this be an issue? I’m also looking at water linked as we may need to do a lot of shallow work less than 10m. I’ve heard USBL isn’t as good in shallow water due to reflection.
First, what are your accuracy expectations?
Quite a bit of our initial testing with the MK II was in a freshwater retention pond behind our shop with a max depth of 6’ or so. Soft and mucky bottom, so I don’t imagine we were getting a lot of hard reflection. There, we were getting heading to a couple of degrees and location accuracy to less than a foot. When we went dual channel (Rx & Tx both topside and rover) we got that down to a few inches if we gave it a moment to settle after fast movements.
I wouldn’t sweat the blanket statement for a shallow depth application, there are just too many factors to consider to say anything would or wouldn’t work.
Our latest tests were under a barge in magnetic deprived environments, hard sand bottom, like 12’ deep. Performance was about the same there, and we didn’t see the barge bottom reflections like we predicted. It works accurate enough for us to drive straight lines on the bottom of the barge with a +/- 2" off track cumulative error over a 200’ run. Compass with a good L2 Nav controller would do almost as well, its just we have so much mag interference in that environ.
On the cost, if you are using it daily, get the MK III if possible. Getting the GPS fix for both the ROV and topside units (for the time sync) is sometimes a bit difficult when you are bouncing around inside a RHIB in rough seas. The MK III sort of obviates that issue and streamlines the deployment process a bit, where you can mount the gear, power up, and deploy. One less thing to worry about. As well, our tendency when we start to drift more than we like is to stop, get topside, calibrate again, then continue the mission. It can be disruptive to say the least, and isn’t always the problem / solution.
We considered the Water Linked, but at the time it wasn’t available, was more expensive, and our client wanted us to find a manufacturer we could parter with. I’d love to test it against our current solutions, now that we have more experience optimizing things - but we are pretty happy.
What type of survey are you planning? Searching? Mapping? Water quality? They are all a bit different in the execution and how you would tune it all for the task. I’m super curious, as we have seen some interesting artifacts when cavitation cleaning, using side-scan or multi beam, etc. Even some water quality sondes create interesting aspects.
Chandler - thank you for the very informative post. That helps me a lot in determining what may or may not work. I’m setting up a project to recover ghost gear (crab traps primarily). We develop the electronic monitoring systems currently in use on the commercial crab boats here in BC. All of the commercial traps are tagged with RFID chips which they scan every time they haul so we have fairly detailed locations of where potential ghost gear maybe located. My plan was to use the ROV with USBL/LBL to search a given area using a combination of side-scan and grid search. It would make life a lot easier if we can navigate to a potential target instead of dead reckoning. Many of the areas are within 10-20m and a good place to start. I’ve seen other similar efforts online using this method. So precise location is not that critical, certainly a couple of feet is more than acceptable. Duly noted with the MKIII over the MKII. We really don’t want to be doubting are location due to drift and then calibrating, etc, etc. One concern I do have with the USBL is we would be using our boats ability to hold a fixed location with its engine. That means there would be prop cavitation that could interfere?
Awesome project! Ghost traps are a big deal here in Florida as well.
Now I am super curious what your plans for SideScan are, as that is an aspect we have been super eager to test while running the location sonars. We didn’t know if we would need to ‘gate’ the location sonar and just turn it on intermittently to correct a dead reckon drift. We wrote some code for this concept for a surface radar project, using the IMU data to tell us when to take a radar snapshot (theoretically with a clear view of the horizon).
As well, we did some work with side scan data, identifying features and measuring ‘twist’ or rotation of the imagery in-situ. That helps us identify any yaw or heading creep. Once you fuse in all the IMU data, heading, accurate pressure depth, etc. you should be able to drive a fairly accurate grid.
That said, the MK III seems like the best gig. If you are worried about surface cavitation and that noise, just put the topside unit deeper. Dennys may have some more relevant data there, but we haven’t seen much artifact like that as of yet.
Well, now I’m super curious if the MK III, a side scan, and a DVL can be co-located and pinging all at the same time. I haven’t checked the frequencies for ‘compatibility’ and have never tried it. I’m going to go put our MK II dual system on a vehicle with the DVL and see what happens! Then, if you have a bead on a side scan choice, I’d like to try that as well.
Funny how things go sometimes. I think my wording was a little confusing. I meant we’d do a side scan with our boat topside beforehand and then use that data to locate traps. However, all that being said, you now have me thinking of strapping a side scan sonar onto the ROV?
Ha! Yes, on the ROV. We have been researching ethernet side scan solutions for a while now, and have some integrations on our USVs that work quite well.
Right now our most effective solution for surface vehicles is a Garmin black box sonar with a side scan capable transducer. We sort of reverse engineered a bit of the messaging and found the imagery data that we could use live and don’t need the chart plotter. The unit is a bit too big for this class ROV though, and would need to be enclosed.
I’ve always wanted to try an Imagenex ethernet side scan kit, but we haven’t found the funding for it yet.
Not sure if there are other competing products out there, but at some point I think we may just take a Garmin (Airmar) transducer and try to build a PCB…
I’m super interested in this. What do you use to interpret the messages and display the graph without a chartplotter? Did you build something custom, or are you working on top of Matlab, etc?
It is certainly custom. We built a ‘translation’ microcontroller on a PCB to take the data and convert it into digital imagery so we could spit it out most anywhere over IP.
We do a lot of stuff like that, but usually one-off for the need of the day to enable our data collection services. We have been thinking of packaging some of those developments (we have the same concept for surface Radar) but never knew we weren’t the only people who could use it.
On the side scan note, I’m hoping Cerulean will develop something sooner than later. In the meantime, I’m taking a heavy look at the StarFish OEM units from BluePrint Subsea. Does anyone have experience with their products?
The trick in the end game is to visualize all this data together and be able to navigate based on the data received and processed for info in-situ. We have the GCS side we wrote with flow-based rules from received data, but every sensor protocol, data path, and decoding are different. We write so many of these translator bits of code on microcontrollers, it takes forever.
I wish marine sensor manufacturers would follow a standardization like NMEA 2000 or similar…
That’s really cool.
I’ve done lots of sensor integration on autonomous surface vessel projects, but my problem is that unless the datastream is coming in serial rs232 format, I don’t know how to even get started intercepting or analyzing it.
For example, our simrad MFDs transmit sonar and radar data over the Ethernet network to each other. But how do you track down what is what as packets are flying around the Ethernet network?
Is there a utility like Fiddler that lets you analyze the contents of arbitrary network traffic?
Wireshark is perhaps worth looking into