GPS tracking with the Propeller
Phil Pilgrim (PhiPi)
Posts: 23,514
In preparation for an ASV (autonomous surface vehicle) contest this summer, I needed to track the position of a near-shore buoy off of Port Townsend's waterfront. The reason is that the contest involves going out to the buoy, going around it, and returning to the starting point. Because of tidal currents, the buoy can wander considerably with the ebb and flood. So I wanted to accumulate data about its position range, so that contestants could program their ASVs to go around it, regardless of tidal conditions.
To that end, I built a recording GPS unit, housed in a waterproof box, and attached it to the buoy for two days. Here's a photo of the interior of the box:
And here's a photo of the buoy with the box attached:
The hardware consists of a Propeller Backpack (since discontinued), onto which is plugged a Proto-DB prototyping board. On the prototyping board is a PAM-7Q GPS module. I had the module in my junk box and really didn't know where it came from. It turns out that it had come unsoldered from the Parallax GPS module of the same name and that, at some point, I just soldered a header to it so I could use it stand-alone.
I wrote a Perl script (attached, zipped) that translates the raw GPS lat/lon data (in micro degrees) to a .KML file (also attached), so that I could see the track in Google Earth. (The attached Perl file did not produce the attached KML file. It's a later version that smooths the lat/lon data (also attached) according to a Gaussian averaging function.)
The Spin program (attached) waits for the HDOP (horizontal dilution of precision) to go below a certain threshold, then begins recording Lat and Lon every five minutes to an EEPROM file. The unit was powered by four AA batteries, which lasted about 37 hours.
Also attached are a KML file (zipped), which you can load into Google Earth, and a PNG file that you can view directly:
It's notable that the buoy's position clusters around two distinct locations, depending upon tidal conditions. Even more notable is the fact that the NNE cluster is overwhelmingly preferred. This is because, on an ebb tide, the buoy is pulled with the ebbing current. On a flood tide, the near-shore current results from a clockwise gyre set up by the point (Point Hudson) to the northwest, so the current direction is the same as on an ebb tide. (Locals have known this forever, but this confirms it.)
-Phil
To that end, I built a recording GPS unit, housed in a waterproof box, and attached it to the buoy for two days. Here's a photo of the interior of the box:
And here's a photo of the buoy with the box attached:
The hardware consists of a Propeller Backpack (since discontinued), onto which is plugged a Proto-DB prototyping board. On the prototyping board is a PAM-7Q GPS module. I had the module in my junk box and really didn't know where it came from. It turns out that it had come unsoldered from the Parallax GPS module of the same name and that, at some point, I just soldered a header to it so I could use it stand-alone.
I wrote a Perl script (attached, zipped) that translates the raw GPS lat/lon data (in micro degrees) to a .KML file (also attached), so that I could see the track in Google Earth. (The attached Perl file did not produce the attached KML file. It's a later version that smooths the lat/lon data (also attached) according to a Gaussian averaging function.)
The Spin program (attached) waits for the HDOP (horizontal dilution of precision) to go below a certain threshold, then begins recording Lat and Lon every five minutes to an EEPROM file. The unit was powered by four AA batteries, which lasted about 37 hours.
Also attached are a KML file (zipped), which you can load into Google Earth, and a PNG file that you can view directly:
It's notable that the buoy's position clusters around two distinct locations, depending upon tidal conditions. Even more notable is the fact that the NNE cluster is overwhelmingly preferred. This is because, on an ebb tide, the buoy is pulled with the ebbing current. On a flood tide, the near-shore current results from a clockwise gyre set up by the point (Point Hudson) to the northwest, so the current direction is the same as on an ebb tide. (Locals have known this forever, but this confirms it.)
-Phil
Comments
-Phil
Thank you for your very complete and professional application note and file attachments.
I was planning to do something similar and your post will save me considerable time.
I have a project for the near future in need of GPS datalogging, so I was looking through your code and noticed you are logging to EEPROM. My past attempts to do the same gave me issues so I ended up logging to SD since I already had it working. I prefer logging to EEPROM because there is less hardware, AKA smaller total size. Thanks for sharing!
I like the idea of a PERL script to clean up data for KML, but in case you could use a more basic setup in the future for KML data, check out this thread on a Propeller based KML logger. Not sure if Google made changes in the past 9 years to KML formatting that breaks that code, but maybe worth a peek if you haven't seen it before: http://forums.parallax.com/discussion/104049/google-earth-gps-sd-card-logger-complete/p1
-Phil
Your competitor is just starting to think about the competition. He's not nearly as bright as the contest originator and may need a little help with the coding to be competitive. I imagine the competitor would always assume the buoy doesn't really move and just plan a wide envelope of travel around the buoy.
Will this contest be run at the peak of a flood tide? I guess a date needs to be chosen.
Ken Gracey
Ask, and ye shall receive. 'Not sure I can help with Blockly, but there's plenty of Spin code that I can provide. It still needs some work, and I don't yet have a completed craft to test it with yet.
Here's an image of the control box:
It includes an RC receiver (for emergency retrieval), GPS, compass, 2-axis accelerometer (which probably won't be used), XBee (for real-time debugging), and a two-axis brushed-DC motor controller for the paddlewheels. (I'm toying with the idea of replacing the paddlewheels with above-deck ducted fans, but those will need a different controller. Plus, they're pretty noisy and might be too annoying to debug in the marina. There's also the chance that they might make the boogie board burrow into waves.) There are also headers for a downward-looking camera and laser control, along with an underwater thermocouple, none of which have application to the contest.
The buoy won't drag anchor (unless we have a tsunami), so yes, just keep a wide berth around the Google Earth buoy path, and you should be good. That's what I'm planning to do.
Slack tide would be the easiest. Maybe do two heats: one at slack; another at maximum current.
'Hope you can make it, Ken!
-Phil
Addendum: The impetus for this contest is to come up with an ASV (autonomous surface vehicle) that can follow a zig-zag course to chart eelgrass in the near-shore zone. That's the purpose for the downward-looking camera. A friend and I tried using side-scan sonar, but that didn't pan out. His depth finder did a better job detecting bottom vegetation, but it was not able to distinguish eelgrass from other kinds of seaweed. Eelgrass is ecologically important because spawning herring deposit their roe on the grass blades. Without eelgrass, they would not be able to reproduce, and an entire food chain would be adversely affected.
Great project Phil. I had the pleasure of working with a marine biologist from the University of Washington on a seagrass project at the Port of Anacortes. The old Scott pulp mill left a toxic mess when it closed in 1978, so the port took on the task of remediation and restoration of the seagrass ecology. The professor (Sandy Wyllie-Echeverria) was very interested in underwater videography, so I think you might find his publications relevant to what you are aiming to do. My involvement was a Basic Stamp weather logger (~1998) on a pier at the study site, the main thing being light levels, underwater quantum PAR sensors among the incipient eelgrass.
There is also a U.W. marine research site out at Friday Harbor.
I've been obliquely involved with eelgrass tracking for several decades. A different friend of mine owns a research vessel, contracted to Washington's DNR, for charting eelgrass. I built him a video overlay controller (which has since been retired) to allow GPS data to show up on the NTSC video. It was pretty primitive by today's standards, but it did allow one to create a plot of eelgrass beds, at least partly by hand.
__________
Incidentally, looking at a video stream of the bottom, everything seems so clear. But if you look at single frames, it's a blurry mess. 'Amazing what the human visual system can do to extrapolate clarity from streaming frames.
__________
Today, I took the control box and the boogie board, along with a bubble level, down to the marina to determine the correct position for the box, so the center of mass coincides with the center of buoyancy. The box is now attached to the boogie board, but above it. At some point I will make a cutout for it and remount it lower so the camera can see the bottom. I still need to source waterproof boxes for the gear-motors so I can finish the hardware aspect of this project.
-Phil
I didn't record it, unfortunately. And the program doesn't start recording position until the HDOP falls below a certain threshold.
The box was set at about 11 a.m. PDT on 28 May. It recorded every five minutes for about 37 hours. On my to-do list is to color-code the track for ebb and flood, but it will have to be approximate due to the time uncertainty.
-Phil
Animation:
-Phil
Elevation would be great too as that gives us a hint of the tide state and might be more useful.
-Phil
I see there are plenty of youtube videos of eelgrass, like this one from DNR:
Their pictures look pretty clear, but I appreciate what you say, It would be challenging for an automated pattern recognition program.
-Phil
Not at all. That's a very interesting idea, really.
-Phil
-Phil
Current meters have been around for decades:
https://en.wikipedia.org/wiki/Current_meter
In the mid-70s, I was involved with setting and retrieving a recording current meter in Lake Michigan near Chicago. It included a vane for direction and a Savonius rotor for speed. It stayed underwater for several months and was programmed to surface at a specific date and time. The timer triggered an explosive charge that drove a pin out of a shackle, allowing the attached float and line to release so we could hook it and pull the meter and its anchor back to the surface. We arrived at the site about a half-hour ahead of the scheduled time. Right on time, the float appeared, and we hauled the meter aboard. (BTW, this was pre-GPS days. We used Loran to navigate to the recovery spot.)
-Phil
Very cool story. I see you said near Chicago. Was it actually in Indiana, and perhaps a study for the Indiana Dunes National Lakeshore?
-Phil