Are you going to try to take over the world with fleets of autonomous submarines prowling the ocean depths like some kind of supervillian? With a white cat in your lap, minions, the whole nine yards? ARE YOU?

>Maybe this is a dumb question, but how exactly does the â€œscientistâ€ plan to change the properties of water so that you can read weak GPS RF signals if the sub is more than a few meters underwater?

If I were designing a system like that, I’d use GPS for near surface and mount an inertial tracker for deep water. I assume the Gavia does something similar.

Eric is right. GPS is only used on the surface; at depth, an INS or IMU-based navigation solution is common. This may be reinforced with other systems such as a USBL, SBL, or LBL acoustic range-and-bearing system which provides position relative to a surface object of known position (for example, a ship), or even a trusty magnetic compass for heading information.

Does GPSD provide for readouts of time, as well as position? (At the place I worked at before retirement, we used GPS receivers to set our master clocks.) It might be a very useful feature to implement if you haven’t done it already.

>Interesting concept: should GPSD be extended to support position tracking systems that do not use GPS?

We’re heading in that direction. GPSD can do useful things with the take from an AIS (marine Automatic Identification System) receiver now. We already support two makes of electronic compass and yaw/pitch/roll sensor. Down the road I’d like to be able to do aircraft transponders.

What GPSD is morphing into is a general device manager for any kind of sensor that reports location-related datagrams over serial or USB links. Er, or TCP streams. And soon UDP streams as well. GPS management will probably remain its central use, but far from the only one.

Have I mentioned that this project is fun? Er, was fun even before robot submarines?

A few of the cool places DigiTemp has been used – Beowulf cluster at Oak Ridge (since shut down), a robot telescope project (to track mirror temperature and operate some fans) and a bat house. Its always nice to see interesting projects using my code.

>Eric, could you tell us what was this feature request? Inquiring minds want to knowâ€¦

Oh, sure. He wants gpsd to be able to use data handed to the packet sniffer via UDP datagrams. We already support serial (including USB serial) devices and TCP streams – the packet sniffer doesn’t really care how the bitstream arrives except at the single point where it does a read(2) on an fd you hand it. UDP needs a bit more magic plumbing because you can’t read(2) datagrams, you have to recv(2) or recvfrom(2) them. But there’s no difficulty in principle, and I’ve already seen a proof-of-concept from one of my devs. I expect the feature to land shortly.

Well, the golden-colored one (GAVIA Scientific) certainly looks like it have “frickin’ laser mounted on frickin’ head” ;-)
But I’m quite certain that it is something else (obstacke avoidance sonar, or sound velocity meter), or something else.

I’m the scientist with the submarine! Eric shared your discussion with me. I’m thrilled to see your interest so I thought I’d post and answer some of your questions. Our submarine is co-operated between the Coastal Sediments, Hydrodynamics and Engineering Lab at the University of Delaware (http://www.geology.udel.edu/cshel/CSHEL/Welcome.html) and the Center for Coastal and Ocean Mapping at the University of New Hampshire (www.ccom.unh.edu)

First, sadly, no, we do not have a laser on our submarine – yet. We have seriously talked about putting a blue-green laser scanner on it for ultra-high resolution scanning of the seafloor.

The primary mission of our submarine is seafloor (or lake floor) mapping and water chemistry. In addition to a collision avoidance sonar in the nose, there are two bottom mapping sonars along the sides. One is a “sidescan” sonar which casts acoustic shallows of objects sticking up from the bottom providing a black and white silhouette. The other is a “phase measuring bathymetric sidescan” which can produce a topographic map of the seafloor.

Accurate navigation is very important for our mapping efforts. While on the surface we navigate via GPS. This is fed into an inertial navigation system which is used independently for navigation when the AUV is submerged. The 1-PPS signal on the GPS also provides a critical timing source – even when submerged – to keep all the sensors temporally in synch.

Sadly the manufacturer did not have the presence of mind to integrate the GPS and 1-PPS signal into the Linux control processor for time keeping. Rather they coarsely monitor the GPS on startup and set the time once, letting it drift thereafter. The obvious answer is to integrate the GPS and 1-PPS signal with NTP (perhaps via gpsd) to make the AUV a stratum-1 time server. Then other onboard computers can use NTP client software to maintain their own synch to the control processor. That is my goal and why I’ve been bothering the folks at gpsd. Although we have to make architectural changes to get the 1-PPS signal into our control processor, I’m hoping that I can run a gpsd server and utilize ntp off the raw, jittery NMEA strings themselves as a first step.

I’m sure you are wondering what happens to the 1-PPS timing signal from the GPS while the AUV is submerged. The GPS in our system does not send a 1-PPS until it has a GPS fix, but afterward continues sending them, unregulated by the GPS solution, even if the GPS can no longer see any satellites. We have tested the drift of this 1-PPS signal with no fix and found that the drift rate is small over the 3 hours or so of a given mission. Moreover, it is the relative timing between systems for which critical timing is key, rather than the absolute synch to UTC time.

Fire away if you have more questions – or feel free to contact me directly.

>I think you slept through the latter third of your class on â€œMonomaniacal Villainyâ€ at Bond Villain Finishing School. Probably got distracted by the catâ€¦

No, the truth is they kicked me out of villain finishing school too soon. I kept asking why we were trying to keep all the techniques secret when iterative improvement by many eyeballs would enable us to debug our sinister plans more rapidly. “Who are we kidding, ourselves?” I said. “It’s not like we actually have any secrets any more, not since the Evil Overlord List got published.” Didn’t make me popular.

I did pull a straight 4.0 in mad evil laughter and megalomaniacal monologues, though. And everybody said I had the sexiest minionettes.

Iâ€™m hoping that I can run a gpsd server and utilize ntp off the raw, jittery NMEA strings themselves as a first step.

If the control processor has Python installed, Debian-based systems have a nice package available in universe called python-gps, which has a very nice set of Python classes for getting data out of gpsd. A sufficiently-skilled Python programmer could write a small Python program to grab the time data from gpsd in and set the system clock with it in virtually no time at all. In fact, I wouldn’t be very surprised to learn that one already exists somewhere.

I wonder how accurately one could determine location with no data other than an internet and/or wifi connection? You could at least triangulate a little bit… and then there are those reports that Google’s street-view vans are logging MAC addresses of any wireless hubs they run across…

Thanks! I was not aware of python-gps – I’ll have a look. The tricky part is that time must continue to monotonically increase, so you have to be very careful about a hard reset of the clock which can make time-stamps go backward in time. This is why ntp is desirable, since it simply adjusts the tick-rate.