Navigation, Location and Dead Reckoning


I see OpenROV project as quite a wide one, where many research fields can be opened.

Navigation, hydrodynamics, electronics, robotics, structures ........ and the omnipresent MATH that lays below all of them.

Almost anybody could find his interest field inside this project.

Let me start one of them .....

Having three accelerometers onboard the ROV allows for inertial navigation by means of Dead Reckoning.

Knowing where the ROV is located at a given time t, and by sampling all accelerometers readings along time, actual location X, Y, Z of the ROV can be known.

Data scatering and measurement errors are the problem to be solved.

As we have no means for math writting inside the forum, I've attached a brief document about how the system could work, from my point of view, for those who could be interested on the question.


842-DR.pdf (116 KB)

Acoustic Location System
GPS for ROV Surface Navigation
Underwater positioning GPS by triangulation?
Underwater metal detector

Hi Ion,

For the data filtering, have you considered a Kalman filter? It's very common in many dsp applications - especially dead reckoning.


I would be curious to see what kind of accuracy you could get. I assume even with a high sampling rate, filtering will get you cumulative errors.On the other hand I suspect the relative low speed these ROV's are operating (changing direction) at would introduce a problem with regards to the sensitivity needed of the accelerometer.

Does the 9-axis IMU sensor do any filtering or processing on its own or is it just raw data?


Nice writeup Ion. I have been advocating this approach for a while and am willing to work with the group on progressing this area. I am still getting to know my IMU and the sw that runs on it. I am interested in visualization of the position data. I also have started to look at integrating the IMU data stream with ROS (robot operating system). ROS has visualization and data logging packages.

Back to DR. I have run into a sw package called Octave that is open source and can run programs written for MathLab. So the matrix inversions needed for DR can be run. I haven't tried it on the BeagleBone yet, but it can be run on the surface laptop (plenty of cpu cycles here).

It is also interesting to correct the accumulated errors with DR when accurate positioning info is available. Our pressure sensor can provide reasonably accurate depth info and can be used to update that part of the DR info periodically. If we later include any acoustic beacon info (from the launch vessel, any surface or uw buoy).

I guess the first step would be to implement the DR equations, conduct some trials (where known position info is available) and see what errors we are running.


Hi all:

Nice to meet you again on another thread.

May be we could check some filters and compare results, in the theory before and in seatrials after.

As I see it, all computations would be performed by the "surface" computer. It means quite a big computing capacity is availabe.

Sampling rate is a key question. Too low, too much cumulative errors, too fast, too much noise. But .... Wouldn't it be possible designing a system which could self addapt the rate to the results ?

Provided that a value for the most probable error is computed, and that the computation is obtained from the prior set of data, the change in error, can be related to the sampling rate and data variance, providing a way to adjust the first in order to minimize the second.

Having a third source of data, let's say ... an absolute one (As Jim Trezzo has posted), would allow for accurate self corrections.

Lets keep on the work :-) :-)



From what I've seen, professional applications seem to rely on a combination of DVL (Doppler Velocity Log) and HPR (Hydroacoustic Position Reference) for accuracy and correction, but that's pretty complicated. Without correction you're bound to get cumulative errors over time, but another way to reduce the problem a bit (without overcomplicating things) is to have a fixed point you visit every so often to "zero" the error. I.E. if you zero all the axis at a fixed position on the seabed (where you start your survey), and every so often return there (review how much it has drifted) and zero it again before you continue. That could possibly work even if you use several dives to do a survey, and I assume would be useful when testing/comparing different filtering and calculation methods.


Doppler and fixed reference points is the better way. But ........ expensive, complex, and hence not useful for us.

Inertial navigation is a true option, and the only independent from external sources avilable by now.

Inertial Navigation has only a partiallly common part with the classic Dead Reckonig.

The classic way, worked almost only from speeds and times. Time can be accurately measured, but speeds are another "song".

Speed measurement is always relative and hence big uncertainties arrive if all "noise" factors are not known.

I'll use the same example I used in my last class about this subject........

If Im onboard a train running at 100m/s, walking with my friend A, at 10m/s along and with respect to the train, while you are standing on the platform.

From your point of view, we'd be moving at 90m/s or at 110m/s

But from A point of view, Im not moving (we're walking togheder). True ?

Speed measurements are always relative. If there is no knowledge about all speeds, it would be impossible to know where will A and me be after a time t with repect to any of the reference frames.

Let's now go with another situation. Inside the train again. Same observers, same conditions, but at this time, at a given time, I'll stop walking and will start running.

Let's say my speed changes from 10m/s to 20m/s in one second.

What would any observer measure ?

You, from the platform, with no knowledge of the train's, A`s or my speed, would hence realize that my speed has changed, and would measure a change of 10 m/s in 1 second.

From A point of view, the change in my speed would be the same.

And ....what about me? I'd measure the same change by means of INERTIA that would exert a force against the motion that would be proportional to the moving mass(me).

Inside Newtonian environments(Non measurable Relativistic effects) accelerations are ABSOLUTE.

In the old times, there was no way for accelerations measurements, but nowadays, we can get highly accurate lectures of it.

Inertial Navigation could be, from the theoretical point of view, the DERIVATIVE with respect to time of the old classic Dead Reckoning.

Drift caused from winds(surface vessels) or currents, can be directly measured from any chosen reference frame, from only the Inertial effects due to changes in the motion state of the moving body. In our case, the ROV.

We could even get a better approach, as we are able to measure not only accelerations(changes in speed), but changes in the acceleration itself. It means a third derivative can be used, that by comparison (integration) with the actual value of acceleration (second derivative) can be used for accuracy improvement.

With six degrees of freedom (DOF) accelerometers(linear-angular X,Y,Z) a nice approach to the real location is not "complex" to be computed.

The key is in the filtering algorithm design. I posted the simpler one, but we could refine it.

The Kalman filter looks a good point for starting.

Albeit calling Dead Reckoning to this system makes it easier to understand, Inertial Navigation has really a little thing to do with it.

Would like to start seriously working on this project. Who is for joining a team for the works ?

Best regards



I'm somewhat familiar with what you are getting at, and I was not suggesting that internal reference isn't the way to go. I'm pursuing a somewhat similar problem on a work class ROV, basically having a track-plot on a map using the position outputs from a DVL system, but with other external correction like HPR. My experience is that it gets inaccurate somewhat over time (cumulative error). So if I make a seabed map with a sonar and return to my starting point, my position on the map is slightly off. The practical workaround for this so far has simply been to position the ROV on a known spot and reset/zero the output from the DVL from time to time (in a sense an external correction). The practical benefit to that comes if I work in the same area over several dives I can continue from where I left off when I zero the DVL output in the same spot every time.

I just recently started reading in this forum, and I'm keen to start building an OpenROV of my own to get a deeper understanding of the technical challenges and practical applications of ROV's in general. The added benefit is that I have something to do when its to calm to sail or to cold in the water to go scuba diving.


Jon, which is the same than "Ion", hehehe. Pleased to meet you.

Yes, I missunderstood you. A reference point to be periodically checked is a good way for corrections and errors checking.

My practical experience inside the Inertial Navigation systems was adquired during two, five months each, Polar Surveys, I was engaged on as ship Chieff mate+senior naval building technician, 6/7 years ago (Team by one icebreaker+chopper, two minisubs and scientific equipment). By the way, may be the best expereince in my whole life.

Of course our equipments were quite expensive, composed by hundreds of accelerometers inside an "all with all" information sharing array. The whole information was processed by two Sun stations onboard, allowing us to get a possition mark (precission better than 1cm) in real time.

We had a duplicated possitioning system, composed by a similar GPS receivers array. Accuracy from one system was not better than the other, mainly at high latitudes.

Thats of course out of our field. Surely with that fixed reference "waypoint" we could refine our future system with a kind of selfcorrecting factor.

Hope to count on you for the practical development.

First thing we need for starting, I think, is a few minutes record of the acelerometers readings, in order to be able to study their practical behaviour.

Thanks for your comments and contributions.

Kind regards.


A single accelerometer is very hard to use, the data is usually biased and noisy, and tends to drift over time and with temperature changes. There are also rectifying effects in integration, where you might integrate more velocity in one direction than another. Also, I wonder what the effect of water motion will be. In a boat, waves will tend to be averaged out over a large area, but on something as small as an ROV, the amplitude of the wave motion near the surface could be on the same order of as the size of the ROV, and in that circumstance the motion of the ROV might be washed out by wave motion. It seems like a difficult problem with several interesting challenges.

A lot of accelerometers is an interesting approach to some of these issues. Perhaps there could be four, on the most distant corners of the ROV. I think you will need a gyroscope as well, to deduce bearing, although these too drift.


Hi Nick:

Thaks for your comments.

May be with the help of you all, we will finally arrive to a reasonable and practical solution... or at least, to an interesting research project.


Kalman filter as main data treatment algorithm.

Depth sensor as correcting device.

Fixed location and repeated visits to the rendez vous point as correction system again.

Perhaps ....

Doppler check.

Surface beacom.

Gyroscope(I fully agree, it's a mayor help)

Could anybody send/post/link a record of raw accelerometers readings ?



Thank you Ion,

Good work.

Any ideas on how to implement this strategy if the launch vehicle is no anchored? In the drift dive scenario the initial velocity of the ROV would be nonzero and potentially unknown.

Perhaps user input would be needed for manual entry of drift velocity (initial velocity) or perhaps an onboard GPS sensor would be warranted. For example the surface module could include a gps sensor and the laptop would use that data, or the ROV could contain a gps module and the initial velocity could be set prior to deployment.


A day to let the car at home(Windy, blizzard and cold)

Hi Quantum ¡¡

Im for the boat GPS solution. Carrying a gps module on the ROV will not be worth the results. It would only work on the surface, when the ROV is onboard or besides the "mother ship".

Now, from the math point of view ....

From accelerometers, we can get --> Speed(1st integration) --> Elongation (2d integration)

From changes in acceleration --> acceleration (let's say initial integration) a checking procedure.

For the Kalman filter application, we have to decide what variable to filter.

I suggest using speeds as input variable, elongations as output and accelerations(That change along time) as control parameter.

External data sources can be used as Navigation aids and included in the filtering algorithm as secondary control parameters.

At the same time, we need any mean for "noise" evaluation. That's why I'd like any ROV user to share a recorded accelerometers readings along 1 minute or longer.

As Nick suggested on his former post. A gyroscope could be a nice help. It would allow the system to make a distinction between a heading change command and a noise effect.

Solidstate Gyroscopic devices are widely used on Model helicopters, hence its an easy and realtively cheap thing.

I'll go just know to check an Heli-model owned by a friend of mine/neighbour to get an idea about weight, size, connections and prices.



Hi Ion,
Yes the surface GPS does sound more useful.
I agree on the next two points.
I think the IMU has gyros doesn’t it.
I’m finishing my build soon, and would be more than happy to log th IMU output. How do I initiate the logging/locate the file?


Hi all ¡¡

For the data treatment and filtering procedure I've been thinking ..... Yes ¡ Hahaha, from time to time, I like thinking a bit.

We require the location and orientation of the ROV, provided by the Three X,Y,Z linear accelerometers and the three gyros.

As checking/control devices we can count on a depth meter (Z coordinate) and a 3D magnetometer included into the IMU

From my point of view, X,Y,Z speeds are required as itermediate datas only.

Hence, at any moment, in epoch t=0, the system state can be represented by a vector R={X, Y, Z, Vx, Vy, Vz, A, B, C}


X,Y,Z are the spatial coordinates

Vx, Vy, Vc are velocities along X, Y and Z axis(Sway, Surge, Heave/Dive)

A, B, C are rotations around X, Y, Z, (Pitch, Roll, Yaw) (From gyros)

Control vector could be given by:

C={0,0,D,0,0,0,mX, mY, mZ} Where D is deduced from the depth meter, and mX, mY, mZ come from the magnetometer.

For error matrixes, a starting assumption of a Covariance=1 could be used. Updating this matrix, would be performed by a computation from the former data-cloud joint.

For the error/noise evaluation, the same procedure above would be fine. The problem is having a good estimation of the initial values.

I think we could get that estimation from a set of raw data recorded from the IMU to be used.

I dont see a mayor mathematical problem for trying to build such model. The only point is building a consistent matrix arragement.

Would like to have some oppinions or comments before even trying to start. May be there are things I didn't take into account or that I even didn't realize that exist.

A Brains storm always better than a single a mind.



Hi Ion,

I agree with your matrices. I am interested to see wither the sensors detection sensitivity will be able to pickup deceleration due to drag. As for filtering noise perhaps a two part analysis would be useful:

1. some sort of time averaging

2. evaluate peak response within the averaging window

The second phase could be useful in detecting sudden short duration acceleration/deceleration events that might otherwise get averaged out. Ex. collisions, turning on motors at peak thrust etc..


Check this out.


Looks like a nice paper with some interesting references. Will give it a read.



Thanks for the link:

From my point of view, this project would have to be approached in steps.

1-) Sensors data filtering.

I think that the Kalman filter solves this one. Other simpler methods could also do the work, but Kalman is the standard, and at the the same time, there is a lot of information about it.

2-) Sensors data integration.

The way a real navigation gyroscope works is not the same than the system installed in the ROV.

While in the former, the reference axes are linked to the "Universe", in the second are fixed to the ROV.

It means that an algorithm is required for getting motion data with respect to the "world". This algorithm must read 3 rotations with respect to the ROV and write the same data but related to the Earth reference system.

The only data source we have for passing from the former to the last system comes from the magnetometer's readings, which are related to the Earth magnetic field. The same happens with linear motions comming from accelerometers.

A "redundant" data-crossing can be got from the Depth meter.

3-) Dead reckoning algorithm.

Once all above solved, adding an autopilot system, able to follow a pre-programmed 3D path, looks to be a trivial question.

Having a file, with rough sensors data along a significant time period, is a required starting point.

Thanks for the link, I'll read it now.



I believe you could add logging statements here, and later process the logfile to plot out the dead reckoning path. We may give this a shot.

Here is a shameless plug for our team blog.