GPS for ROV Surface Navigation


With the availability of an improved IMU/Depth sensor, I have been doing some thinking and discussions with other members, namely @codewithpassion on how to improve ROV positioning, without having to look directly at the ROV. This gets more into the tele-robotics real that @Eric_Stackpole loves.I have also been watching a lot of the OpenROV videos on OpenExplorer and Youtube and have noticed that most dives are relatively shallow, but with some distance attached.

Nothing in this post it to take away from @Jim_Trezzo’s work on an Acoustic Location System because I still believe that is the 100% solution for a vehicle in the water column.

Anyway, @codewithpassion had an intermediate solution to put an independent GPS module on an OpenROV that could relay coordinates back to a base station while the ROV was on the surface. Obviously, once the ROV dove, you would lose GPS signal and you would have to rely on the compass. Even with that hindrance, this concept of knowing where you are while “surface swimming” is important enough that I think it warrants some R&D until @Jim_Trezzo’s system is fully up.

Let me illustrate:

  1. Suppose you have identified a shipwreck on multi-beam sonar data and want to go investigate.
  2. You over lay your data and then take your boat out to the site.
  3. Obviously, you don’t want to anchor on the site and damage it, so you anchor in shallower water.
  4. From here you deploy your ROV in the water.
  5. If you have a GPS module mounted on your ROV sending back positioning data to your laptop, you can see where the ROV is via what is known as a “Google Earth Bridge”. and your vessel and ROV position can be overlaid directly on the multi-beam layer you have made.
  6. Once you are directly over the site, you can engage the vertical thruster and drop down directly on top of the wreck site.
  7. Even if the currents push you a bit, you at least have a general idea where you are or you can use the compass to keep a constant heading toward the site.

I have given the “Independent GPS” option some thought and found a pretty good set-up that would work for my purposes: GPS to Google Earth using Arduino

Even though it is wireless, it would have limited range and be pretty bulky. I could fit it atop my “beast” as @Scott_W calls it and waterproof it, but it wouldn’t fit on a stock OpenROV.

But alas, we have a small computer onboad! I’m no programmer, but would it be possible to split the I2C and integrate a GPS module for surface navigation with an I2C GPS module? The NMEA 0183 positioning data could be sent via the tether instead of wirelessly.

The NMEA 0183 data could then be read via a separate port (like how :8090 is used for the video streamer) and then uploaded to Google Earth to show position in real time in another window.

It might be too much work for what it’s worth, but it would be nice to see where the ROV is in relation to the bathymetry.


Hi @Kevin_K,

This is a great idea. I haven’t gotten as far as thinking how to visually depict the GPS data onto something like Google Maps, but I did buy a small GPS receiver that could be wired into a com port of the BBB. The one I chose was the Adafruit ultimate GPS breakout. Its real small and power consumption was real low, 20’s of mA through acquisition and track.

This is the part here:

I can get a fix with this unit in about 30 seconds on a clear day. Overcast It goes high 30’s. Indoors its useless. I’m skipping any intermediate microcontroller and wiring mine right into the BBB. On the surface, I don’t think there will be any issue getting a GPS fix, though I haven’t gotten that far with it. At this point I’ve temporarily wired it and sat outside to see how it works.

As far as where I see the unit sitting, I am going to put it in the e-tube. The acrylic may interfere with the signal, but not enough to notice. I’ll mount it so the patch is facing the sky, as high up in the e-tube as I can get it. My OpenROV is a little back heavy, so my e-tube typically sits right at the water surface. If I get a chance to try it in water this weekend I’ll let you know how it goes.

I’d like to hear if you get any further with your concept. Thanks for sharing your ideas!



Thanks @lenny_m_baker!

I wish I could do the programming on this one, but my skills are lacking in that area.

The GPS you bought is exactly what I had in mind for a small mounted GPS module. Which port on the BBB were you planning on connecting to? I think the only standard one left is the micro-USB port unless we could split the I2C. Maybe we should look into connecting to the USB?

Here’s the data flow I’m imagining right now for this to work.

GPS Module -> I2C/USB Port on BBB -> BBB -> Tether -> Server Page (i.e. :8070 etc) -> Virtual COM Port -> GooPs (Or Other GE Bridge Software) -> Google Earth


Hi Kevin

Good to hear that your thinking of GPS on the Beast

My 2 cents would be to mount an external antenna similar to what they do on the pro AUV’s (typically GPS/Iridium phone link/RF local (around boat) data link)

Maybe something like what Lenny is suggesting and then a modified External Active GPS Antenna out of the pressure housing to some epoxy (maybe some trial and error as to how well the radio frequencies will pass through it) housing mounted on the top of the Beast


Thanks for the interest @Scott_W. Is this something you could use? I know I find myself wondering where my ROV is whenever I’m in my control cabin on my boat…even if it is like 10 feet away from me.

I’m following on the elevated GPS mast concept. We would need to get it out of the water to read satellite signals properly. However, if we just encase the primary GPS in epoxy a la IMU style, would we need another external antenna?

Also, here is the information from the GooPs FAQ for TCP/IP operations:

How do I interface my application to GooPs?

GooPs can receive data from other applications via a TCP/IP socket. GooPs listens on port 51234 for messages containing NMEA data. If the message is a raw NMEA sentence GooPs will append it to the local vehicle’s data. If the NMEA string is prepended with an ID and host name. GooPs will treat it
as a remote vehicle. GooPs will automatically add any remote vehicle that hasn’t already been manually added.

The format is:


  1. There is no requirement on the id and host names, they are only used to identify the vehicle in the user interface.
  2. The socket must be closed and reopened for each message.
  3. A message can contain multiple NMEA sentences separated by an ascii carriage return/line feed (cr/lf)
  4. You can save bandwidth by only sending GPRMC, GPGGA, and GPVTG sentences. All others are ignored.
  5. Unless you need altitude data you can just send $GPRMC sentences.
  6. Currently only status, timestamp, latitude, longitude, altitude, speed, and heading fields are used)

Algorithm for using the GooPs external API:
For each position received
Format the position data into an NMEA sentence as described above.
Calculate and append the NMEA checksum.
Prepend a name and host to the NMEA sentence.
Create and open the the socket (the destination is port 51234).
Send the sentence.
Close the socket.


Hi Kevin

Yes, I am interested in this concept from a couple of points

I have tried to get the ROV out over a wreck site say 40m offshore with Dom @codewithpassion and rather than try and stumble onto it from underwater navigation being able to drive on the surface and then descend would be a large advantage and less hit and miss (sort of why I am also interested in the Long Range Wireless Buoy)

But in the big picture I’m also really really interested in a more complex AUV search style vehicle and this, with what @Jim_Trezzo @Bob_Anderson and @Carey_McCachern et al are doing with acoustics

and what @Jim_N is doing with optics

Are all worthwhile in that bigger picture for such a vehicle

Anything you do (RE the mapping side of where the vehicle is) may also be of useful to both of the Jims projects (Jim’s squared? :confused: ) as at some stage all 3 “projects” would need to display location of the vehicle (even if only relative location and not absolute position)

Remember to steal from others works and build upon it have a look at the opensource MOOS-IvP (open source C++ modules for providing autonomy on robotic platforms, in particular autonomous marine vehicles) and Goby Underwater Autonomy Project

Not sure but ROS may also be something to have a good look at as well as part of this may already be implemented there

The elevated mast concept seem pretty obvious and the only reason I was suggesting just the antenna rather than epoxy the electronics was more from a versatility point of view. Either will work but an external antenna if it stuffs up (water etc) is cheaper and in the future you can change electronics if you need to over time in the main E tube, but again both are good.

I have used GooPs a fair bit, but only simplistically and only as a tracking resource when searching for new wrecks (basically just a glorified data logger direct into a laptop) not down at a TCP/IP socket level



If it will help you guys get going, I have a basic application that we built that interfaces a generic USB GPS unit with the beagle bone and presents a realtime track of movement over the equivalent of google maps. Will post the link when I get back to the office Monday.


Interesting topic, and one I’ve been thinking about for a while now as well…

My idea was along the lines of what was mentioned in one of the quotes above:

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 re…

Since you would always know where you are (in the boat), and the ROV can have an accelerometer, gyro and magnetometer–couldn’t you simply keep track of its position? Obviously there is vector math to work out, but at the sample rate we’re talking about here in terms of position updates, I wouldn’t think the math would be that difficult. And it could be done on the laptop/PC, instead of the ROV. Even at that, something like the new quad-core Raspberry Pi could easily handle this math. In early tests with the RPi2 unit I’ve been developing for, sensor updates at even 20Hz only take about 50-75% of one processing core–and that’s with an X connection over tunneled SSH. So I can’t imagine that it wouldn’t be possible to do something like this, and certainly others must be working on it as well.

But it’s an interesting subject though, and one very worthwhile.



@Scott_W Funny, it was actually Dom’s retelling of that 40m wreck story with the ferries that had me seriously think about the surface GPS option. I agree, this would be great to work with the boat, buoy, and ROV so you could see all three in relation to each other from above.

I don’t plan to get too far in the weeds on this one. Pretty much just a GPS streamer is all I’m imagining at this point, but as you mentioned, just getting the maps and positioning to work will lead into the other navigation systems.

Ok now I see the concept behind an external antenna. Good point on the replacement factor. That’ll probably happen in seawater.

@badevguru Yes please! Wow, that would make life so much easier and after consideration, USB would be the easiest to integrate, but I think the GPS module will need additional power. I’ll figure out the hardware part.

@tcbetka I think an Inertial Navigation System (INS) is the way ahead for long range AUV/UUVs, but every INS system I know of still requires periodic GPS updates at the surface (yes, even submarines). We had the AN/WSN-7 on the surface ships I was on and for as good as they are, these still require GPS corrections. ’

INS does have the advantage that you don’t need a baseline as an acoustic positioning system does. Both INS and acoustic positioning are still systems of estimation that need to be corrected. Your vehicle will be somewhere in a “circle of error” that gets larger as time progresses without correction.


Oh, no doubt that there will be error–however the velocities we’re talking about here are quite small, so the math requirements shouldn’t be too terribly great…and the errors shouldn’t be all that significant either.

The one caveat in all this is drift. As in current. Depending upon how sensitive the IMU is, there will be a point where motion relative to the water current will be too subtle to detect, and then of course an accurate position calculation will no doubt suffer. So I definitely understand your point about the need for periodic GPS updates. But then again, in the examples you cited (submarines and surface ships), the average velocity those things traveled was many times greater than those of an ROV–so the cumulative error would be greater as well, and thus the need for periodic updates be higher I’d think. That being said, their mass was obviously much greater as well–so they were not as affected by such things are current, wind and tidal activities. The length of a typical ROV mission would be such that error might not be as significant simply because it doesn’t have as long to accumulate, for instance.

But I do agree with your statements. I certainly have nowhere near the sort of experience as you do with long-term travel on a vessel, but I grew up fishing in small boats on rivers and large lakes, so I can certainly appreciate cumulative position error. Still though, it might not hurt for a person to bone up on calculus, dynamics (equations of motion) and linear algebra, and then go do a bit of work on this problem. And in fact I’m in the process of all of that now.

In the end my ROV might still get lost, but at least I’ll be a (mathematically) educated moron…and be able to tell you where it should be.




It’s a little off topic (sorry Kevin :pensive: ) but just trying to relate everything back to a bigger picture

ROV Location the one thing we can all be assured of is that everybody will need different levels of solutions

Some people are buying OpenROV without an IMU - that cool

Some people are using an IMU as just a bit of indication

With the New IMU being more stable hopefully as you suggest some sort of Dead Reckoning utilising Kalman filters (see some of @Jim_N posts) should be capable of giving the ROV’s (subject to current) position to say within 2m. This, which is the least expensive(advanced location) implementation would mean if you saw something interesting you can manually guide the unit straight back to the area

With a visual system location solution (most likely the next $'s up if a down facing camera is part of the solution) as @Jim_N has indicated SVO (Semi-Direct Monocular Visual Odometry) is unstable but good to 0.05m variance in position or alternatively PTAM (Monocular Parallel Tracking and Mapping with Odometry Fusion) is good to 1 to 1.5m variance in position tracking

With @Jim_Trezzo (et al) Acoustic Location System this may have the tightest implementation but will also be the most expensive

The big thing is all of these will fall over and fail to operate at some stage and how these integrate together and assist each other is important. I see this “proposal” as part of that (and why I nudged Kevin to also think also of the other work being carried out). With a GPS mounted on the unit whilst on the surface then Dead Reckoning becomes an absolute position rather than a relative location, with a visual system odometry whist close to the bottom the absolute position become much tighter

Given all of these “projects” in development (and as they are progressing at various paces) it’s great to see how these can all help provide meaningful solutions to problems

The other side of the discussion is once location has becomes more advanced (eg knowing where the ROV is) then there is the question becomes of some Navigation or “back seat driver” (ie how to get it to somewhere you want it to go). Over the last few weeks/months there has become an increasing number of threads associated with

Again understanding everybody will need different levels of solutions and that many small steps forward will add to the overall system

Some people are happy with what we have. Just point the unit in that direction and go, with then an automated heading and depth control if they require it

A somewhat simplistic upgrade to current system where the course or depth can be edited to a specific value (eg type in a compass bearing and the ROV then rotates to the course and then heads off on that controlled heading path)

Some Simplistic “commands” based navigation system that goes in x direction for y seconds and then go in β direction for γ seconds. This would allows relative search pattern like expanding square or parallel tracks) with no account for drift or current (I’m looking forward to this :smirk: as a simplistic middle step for some of the SfM stuff I am playing with even if it is just a kick off and the ROV just keeps expanding the search till I stop it)

Waypoint/Route (whether absolute or relative position) navigation more complex navigation

Full autopilot (cross track error correction etc)

Autonomy (collision avoidance awareness of other units etc)

OK it was off topic but just trying to tie several things back together


Fantastic, isn’t it?


No worries on the detour @Scott_W. I agree, at some point all these positioning/navigation systems will have to be integrated and we can come up with a reasonable estimation of our location.

I guess my little piece of the puzzle is how do we get that positioning data to give a useful reference? My recommendation is that every system outputs NMEA sentences. From here, we can use open-source or software to display it’s location. We’ll already have depth information from the IMU.

GPS was just the first positioning system we can use “off the shelf”. No math, the hardware is already built etc.



Maybe not ideal for the the Jim(s) squared work but also consider using UTM coords (ie just meters)


I’ll have to go look over the software, but I don’t remember seeing anything with UTM inputs. If the Jim(s) use UTM or another coordinate/projection system we might have to do some auto-conversions. Not difficult, but may result in position errors if we go between too many systems.


Isn’t UBlocks Binary more common than NMEA?


I still have some testing after pulling the code off of a test beagle bone… but it should work. Simply plugin just about any USB GPS antenna in to a beagle bone or similar linux computer and install and run this code to get a map that shows the GPS track on a map.


Wow, thanks Brian! Let me try loading this up on a spare Beagle I lying around.


Wow, a lot of chatter on this thread since the last time I looked. I like all of the ideas bouncing around.

I’ve had my Adafruit GPS receiver lying around for a while, I finally got to tinkering with it.

I noticed that there is a 5th Serial port on the P8 connector of the BBB. Since the P8 connector isn’t used, I’m guessing this com port is available for use.

Separately, I put gpsd on second BBB I have and I was able to use com port 1 to pull GPS data. This was a non-OROV setup, but a good test.

So…if this works like I think it will, we could wire up a serial GPS receiver (like the Adafruit one) to com port 5 of the BBB (on P8), gpsd will receive the NMEA sentences via com port 5, and then gpsd will provide GPS data to anything on the BBB listening to the gpsd TCP port.


@lenny_m_baker Sounds like a good plan. Do you think you could get it to integrate with Brian’s GPS server program?

I ordered one of the Garmin USB GPS units for my support vessel and I should be testing it this weekend. After that, I’ll try integrating with Brian’s BBB program