Home        Store        Learn        Blog

ROV and AUV Localization an Introduction

Hey Blue Robotics Community!

Relatively frequently I see people asking about, hovering, dead reckoning, and using GPS or IMUs for localization. This is often enough I think perhaps it would be useful to have a small guide on localizing underwater vehicles. This a first draft and should be considered an introductory guide. Any comments, criticisms, or things that I left off are welcomed and appreciated.

Why is localization a problem for underwater vehicles?

In the field of in air robotics, localization, in generality, is a solved problem; the Global Positioning System, or GPS, can tell us global position down to centimeter accuracy. As we all soon find out in our underwater expeditions, magnetic waves used for all common forms of wireless communications do not penetrate water. This is why we use wired tethers. GPS uses electromagnetic waves to relay information from orbiting satellites to the GPS device on the ground. *A note is needed here, there are some exceptions and nuance to this entire guide that I have left out for the sake of brevity.

Okay so I can’t use GPS, why don’t I just use my IMU? Double Integrating Acceleration gives displacement right?

While true that an ideal IMU can be used as a self contained localization system, hobby grade and even professional grade IMUs are very noisy. When double integrating the error builds exponentially. We once ran an experiment where we left our vehicle sitting for 1 hour and measured the drift from this localization technique, we found that we had traveled several thousand miles during that time and the vehicle thought it was a couple cities away. This being said IMUs are wonderful tools for telling the current orientation of the vehicle.

I would like to stop here for a moment and say for most applications of ROVs and even AUVs this is plenty; that realistically having the vehicle’s orientation but not its position is sufficient for most applications. I would recommend seriously evaluating why you think you need full localization and pursuing any possible workarounds first. I say this because localization is huge step up in terms of price and or complexity. The sensor package needed to do this can easily be 20 times the cost of the rest of the vehicle. I will discuss some low cost solutions as well but note, I have never seen success with them outside a lab or used them personally and they take a considerable amount of skill and time to implement. I discuss them here to give a complete overview and so that underwater localization moves forward from the current solution, throw money at it till you know where you are.

Localization Solutions

So now for the actual information. This guide will discuss Doppler Velocity Loggers (DVL), Ultra Short Baseline systems (USBL), DIY acoustic transponder systems, Simultaneous Localization and Mapping (SLAM) using both optical and sonar solutions, and optical flow using cameras and side scan sonars. (If I missed anything please tell me.)

Off the Shelf Solutions

DVL, and USBL are turnkey solutions and made by several companies. Both are acoustic devices but use vastly different principles of operation. Despite their differences, for the purposes of this discussion their major advantages are the same, you can just buy them and they work, and will likely have much higher precision than the other solutions. DVLs send acoustic pings to the bottom and record the doppler shift of the reflected ping. This gives the velocity of the vehicle relative to the sea floor. By integration we can determine the position of the vehicle. The down side to DVLs is that they rely on an unobstructed area between the below the vehicle, and there can be error caused by debris on the seafloor(pipes, steep slopes boulders). Additionally DVL’s have a maximum altitude off the seafloor. The major advantages of the DVL are that it is self contained, the unit is only on the vehicle and doesn’t need a transponder at a fixed location. USBL are a system of a transponder on the vehicle and a transceiver on the surface. The transceiver determines the range and bearing to the transponder on the vehicle. The Disadvantages of a USBL are that there are two separate units, one on the vehicle and one at a fixed location. The advantages of the USBL is the fixed reference location on the surface as well as cost.

Do it Yourself Solutions

It is relatively feasible to design your own USBL type system with a pinger on the surface or vehicle and a passive sonar array that can determine the range and bearing to said pinger. Either make or buy a pinger and a passive sonar array to give range and bearing to the pinger. Much more work and expertise needed to do this but probably can be done for 1/20-1/5 the price of a DVL. The limitations on this are refresh rate and accuracy, how often and how far does the pinger ping, and how accurately can the passive sonar array determine the range and angle. As a note for this the Digital Signal Processing on this type of system, while to DSP professionals is quite trivial it requires a strong understanding of the principles and techniques used. Some interesting threads over at Open ROV on making Acoustic modems which have a lot of overlap.

SLAM, Simultaneous localization and mapping has been a hot topic in robotics in recent years and can be adapted for underwater use. This can be done using cameras or sonars. With cameras limitations are range and features, often there are simply not enough features that we can see with our underwater cameras for SLAM algorithms to work. The same principles can be applied to imaging sonars, note that sonars are actually fairly noisy, and the amount of noise in them may make it difficult for computer interpretation. Further with the mechanical scanning sonars that are more affordable the refresh rate is going to be a limiting factor, and a multibeam imaging sonar is going to be as, if not more, expensive than a DVL or USBL system.

Optical Flow tracking, in recent years I have seen a number of AUVs attempt to use optical flow with a downward camera to extract localization. This involves seeing how far features under the vehicle have moved between frames of a downward camera, and determining the vehicle’s displacement from that. While on face value this seems a relatively straightforward and low cost solution I have never seen or heard of it working on an AUV. I have several theories as to why this is any as likely as another. 1 most of the test time for these vehicles is in featureless bottomed pools. The pre made libraries assume a lense model without clear hulls and water in the way. The vehicle’s pitch and change heights which can interfere. Likely it is some combination of these, and by no means is it impossible to use optical flow, just I have seen many people pursuing this solution without success.

SideScan Sonar Flow? I honestly don’t fully understand the mechanics of side scan sonars so I would call on the more experienced members of this forum to comment on this, but it may be feasible to use a side scan sonar in place of a camera in some sort of optical flow system.

Disclosures: I have been working on AUVs for the last 7 years, all of the vehicles I have worked on have either had no localization system or has used a DVL. I am far from an expert in on this topic so I welcome anyone to comment or criticize with anything you think I have wrong or should add.



@Pierson Glad to have you join us here! That is an excellent write-up on navigation techniques.

I agree that a DVL or USBL is the best option out there, unfortunately, there are so far outside our price range that there isn’t a lot of hope there, which is what is forcing us to look at other alternatives.

What about using an altimeter (single beam sonar) as a poor-man’s DVL? I have seen the Bluefin Sandshark and Riptide UUV up close and got a chance to talk with the hardware developers. These two units have nothing but GPS on the surface, an IMU, a compass, a depth sensor and an altimeter for their navigation. Of course customers have the option to add DVLs and USBLs, but when asked how well they would do for side scan nav inputs, I was told “good enough”.

In the end, you may be right and we may just have to settle for navigation via underwater orientation (i.e. fixed compass courses) for the time being.

Hey, I just want to say that this is really great and the AUV/ROV community could use a whole lot more of this type of contribution. My AUV team is very new to all of this, and more resources like this really help us out. Thanks!

Thanks for the complements, I am far from an expert in this but figured it would be valuable to share some insights gained from facing this problem for a while.

@kevin Yes I am truly glad to have a DVL but understand that it is out of scope for most projects. I think that forgoing a DVL or USBL a single point altimeter is probably a great addition. With an altimeter I would suspect that the altitude hold could be greatly improved over just a pressure sensor. I honestly don’t think that a DIY DVL or gaining frequency data from an altimeter is feasible. The DSP of determining frequency is quite difficult, but if anyone has attempted this or has any insights into the process please correct me. Further I can’t anyway to try and reconstruct horizontal displacement with a practical number of “altimeters” any thoughts? Sonar SLAM is basically this concept.

@micheal Jumping into the AUV world quite difficult. CUAUV has some great resources. If there is interest perhaps we can have a few of these guides on topics that the community is interested in. Likely we would need a few people willing to write them. Are there topics people would like something like this for?

1 Like

So I found another UUV using BR Thrusters, this time from Russia. http://www.navyrecognition.com/index.php/news/defence-news/2017/july-2017-navy-naval-forces-defense-industry-technology-maritime-security-global-news/5373-rubin-central-design-bureau-unveiled-the-amulet-uuv.html

It seems this one uses just an altimeter/echosounder as well.


SSS do not work very well on an ROV. The nature of SSS data likes a linear movement of the instrument otherwise you see a lot of smears in the data.

There are a couple of ROVs that are built specifically for hydrographic purposes but they are hydro-dynamically shaped with a the ability to move forward at about 4.5 knots. The ROV pilot needs to be thoughtful of the use of the ROV as there is a significant difference in using an ROV for hydrography or construction/inspection work.

AUV’s on the other hand produce beautiful SSS, SBP and MBES data, positioned using an INS/DVL with drift corrected by a decent USBL system. Some of the cleanest data you will see.

1 Like

@pierson-connors I’m very new to AUV’s (and the broader field of engineering and research, currently an undergrad in Computer Engineering) and I found this thread to be an incredibly helpful starting point, so thank you! I’m wondering if you or anyone else following the thread has any insight into using a Kalman Filter to improve localization. I’m working with the BlueROV2 , and as of now solely have IMU data as an input for my would be Kalman Filter.

A Kalman filter will combine multiple data points and uncertainties to give you the best estimate of a particular value. I’ve used a Kalman filter to estimate depth by filtering the Bar30 data with good results. I also added the IMU data, and as you expect it does improve the resulting estimate, particularly when the ROV is moving rapidly.

However, a Kalman filter and an inexpensive (electronic) IMU will not do a good job estimating X and Y position. Double-integrating the error blows up the uncertainly very quickly. I had to dive into the math to convince myself… there’s just no way to get it to work with inexpensive IMUs.

There is one more source of X and Y data: the commands given to the thrusters can provide an estimate of position. You’re only integrating once, so the error doesn’t blow up as quickly. However, an ROV isn’t the best vehicle shape for this: you have to model drag, and the drag model for an ROV is very complex. A glider would work much better.

I’m currently working on tracking position using fiducial (ArUco) markers. Obviously these only work in controlled environments, but they do work well. If nothing else, the markers will provide a decent ground truth for experimenting with optical flow algorithms.

@clyde, thank you for the post. I have looked at gliders as a model, but unfortunately due to the major differences in movement and drag, as you mentioned, the ROV is significantly different. I’ve managed to implement a linear Kalman Filter in one dimension (x) in a simulator I made in Python (graph attached) showing distance traveled by ROV in each step.
The model is based off ideal conditions, where the noise in the IMU was measured in a calm, shallow pool environment with little to no current / disturbance in the water. I imagine the noise from any moving body of water (such as a larger lake or river) would be too significant to receive valid estimates from solely IMU data.
I do plan on “injecting” GPS data every 5 or 10 steps to simulate the ROV surfacing for GPS signal, to see if I can reduce the margin of error further. Let me know what you think!

Thanks again for sharing your own experience.

This is using thruster input (or lack thereof) + IMU? Position in cm? Nice results!

1 Like

Position in meters, using solely IMU data (using basic double integration script in Python to get the “noisy measurement”, then feeding in to the Kalman Filter and getting the posteriori estimate. I’ll try and implement it real time on the ROV tomorrow, will keep you posted with an update shortly after!

ding-dong, special delivery: https://www.matthewparrilla.com/post/inertial-navigation-marine-robotics/

1 Like

I really wish I had found that article sooner, thanks for saving the day again @jwalser!
Saw on another thread that you mentioned implementing the EKF module from the ArduSub firmware on the Pixhawk. I’m trying to write a script in Python that uses that module, but I’m not sure how that should look like. Namely, could I even use the module detailed here, as it relies on the ArduPilot firmware and was developed from drones?