After half a year of finding an adequate platform for the surveying system, we returned to the roots of the project: The survey of lakes. Further on, the project was called "Sea-Survey". The reaseon for that name did not arise from gigantomanic phantasies of surveying the oceans but in German the word for lake is "See" and the pronounciation is a little bit like "sea" in english, and this gives the project a kind of international touch :-). And -maybe in the near future- we might use the system for finding reefs and shipwrecks in the mediteranean sea, which is one of our beloved diving sites.
I am also talking of "we" instead of "i", because meanwhile the project attracted some of my colleages, who helped a lot, especially for the data conversion software and the 3d vizualization.
Thanks to Robert, Frank, Uli and Jochen.
One of the key requirements of the whole project was:
-keep it as simple and cheap as possible-
In terms of "workload" and "time-spent-swimming-in-the-lake" it definitely was not!
But, in terms of hardware and software costs, compared to professional systems, it was.
So we tried to use as much as possible "free" Software for the data processing.
The hardware cost added up to under 1.000$ (not counted the the "titaniced" Garmin etrex summit), which i find is still adequate.
The mission-planning tool was Google-Earth.
The analysis and PID-loop optimization tool was Google Earth.
The vizualization and publishing tool was Google-Earth.
The ArduPilot firmware development tool was not Google Earth, we used the Arduino platform instead :-)
The "extract-lat-lon-depth-from-NMEA-and-convert-it-to-something-useful"-tool was done by a PERL-script, written by Frank.
The "convert-the-whole-file-generated-by-Frank-to-UTM-data"-tool was a C-Program, that was written/adapted by me, consisting mainly of a WGS84 to UTM conversion routine that i found somewhere in a corner of the internet.
The 3D Vizualization was done by a MatLab script, written by Jochen. (I was lucky, knowing somebody who had a valid licence). Still working on this issue, because it will definitely be no lo-cost solution if you have to buy a MatLab licence. We tried SciLab instead, a FreeWare tool, which is close to MatLab, but it lacks in some essential functions that ease 3D vizualization.
The NMEA-data conversion to Google-Earth was done via a server-based tool called "GPS Visualizer" that can be found on this site: http://www.gpsvisualizer.com/map_input?form=googleearth
This tool is absolutely great! you can upload up to 3 NMEA Data files and convert it to .kml or .kmz files. The result can be viewed with Google Earth. As an option, you can convert every NMEA sentence to a waypoint, that contains all relevant data like speed, bearing, time and position.
Lets go back to the mission planning:
In Google Earth, we created a path, that merely was a zigzag or meander-pattern for the criscrossing of the lake (we are still looking for an optimal pattern). The path was then exported as a .kml file, that contains the latitude and longitude coordinates covered among lots of XML data. With a text-editor and some "copy-paste-search-and replace" operations we had a "const" data field that was pasted into the ArduPilot code.
Yes i know!
That can all be done much easier with the "ArduPilot config tool", but we are talking about the past!
I still prefer putting the waypoint data into a predefined array instead of the eeprom for several reasons:
- it is easier to handle
- i still use large parts of the V1.0 code of ArduPilot as reference.
- the space left in the Flash and RAM can hold up to several hundred
of waypoints, which is absolutely sufficient for a multi-hour mission, so why bother?
- you have to connect the FTDI-adapter and to disconnect the GPS module anyway, so there is no much difference between loading up the new code or loading up the new mission data into the EEPROM. Hopefully we will have ArduPilot-Mega available soon in Germany, which will surely change my opinion. I personally prefer having lots of UARTs in a system, but this is another story...
Much text, no pictures till now, so here we go:
This is the same lake, polluted with yellow and blue color, how awful!
The yellow one is a path, that was created by Google Earth and converted to a "C" constant array, that forms the waypoints. The blue one is the "real" path, the ship took. The oscillations are a special case, that will be addressed in one of the next episodes. The circle on the right side came from a collision with a buoy, that was there (the only one in the lake and i hit it...)
The data from the sonar system was sampled with another data-logger, i mentioned earlier. This one had the advantage, that the RS232 drivers are already on the PCB, so the output of the sonar´s NNMEA data could be directly fed into the datalogger. Anyway, if had known earlier, i had would have used the SparkFun one, because it is half the price and the firmware is open-source. The NMEA data from the sonar, which contained the GPS position and the depth information was converted with a perl script to a simple text file, which contains only three fields: latitude, longitude and depth.
In the first approach we had a simple "lat/lon-to-something-like x/y" conversion, but it lacked in accuracy and the picture was distorted.
For a 3D-representation, we converted the the latitude-longitude values to an UTM projection, which is better to handle.
I found some C-code fragments in the internet, which does this calculation. After this second conversion we have a file that contains the northing and easting values and the depth in meters.
so in short, we got the NMEA file, that looked like that:
$SDDPT,2.7,0.0*52
$SDDBT,9.0,f,2.7,M,1.5,F*0E
$GPAPB,,,,,,,,,,,,,,*44
$GPGLL,4821.0295,N,01001.2870,E,064449,A*2D
$GPRMB,,,,,,,,,,,,,*66
$GPRMC,064449,A,4821.0295,N,01001.2870,E,1.3,257.0,060509,0.6,E*7F
$GPGGA,064449,4821.0295,N,01001.2870,E,2,7,1.20,476,M,,,1,0*0B
$GPGSA,A,3,11,,20,14,19,17,28,,120,,,,2.30,1.20,2.00*32
$GPGSV,3,1,9,11,78,274,45,32,74,238,,20,42,245,42,14,35,53,39*78
$GPGSV,3,2,9,19,33,171,40,17,18,317,40,28,16,281,41,3,5,165,*43
$GPGSV,3,3,9,120,29,212,35*4F
$SDMTW,14.4,C*05
$SDDPT,2.9,0.0*5C
$SDDBT,9.8,f,2.9,M,1.6,F*0B
after the first conversion it looked something like that:
10.0214716666667,48.3505433333333,2.7
10.0214683333333,48.35055,2.9
10.0214633333333,48.3505566666667,2.7
10.0214583333333,48.350565,2.3
10.021455,48.350575,2.1
10.0214566666667,48.3505816666667,1.9
10.0214566666667,48.3505916666667,1.8
and after the UTM conversion it looked like that:
575685.808035, 5355782.793725, 1.100000
575685.064694, 5355782.969104, 1.200000
575684.321354, 5355783.144484, 1.300000
575683.580482, 5355783.134613, 1.200000
575682.713664, 5355783.308347, 1.100000
575681.599888, 5355783.478792, 1.100000
Please note: This fragments do not correspond, i took it out of the converted files arbitrary.
This file was finally fed into a matlab-script, that does the 3d visualization.
And this will be the story in episode 6.....
Comments
Any way 3D visualization data/photo will be interesting hopefully in EP 6