You may wonder why the world needs Yet-Another-Ground-Control-Station (YAGCS).
The following design goals, which are highly subjective, came to my mind when I started to work on this little project:
- If somehow possible, a GCS should not rely on libraries or tools whose distribution is limited for reasons such as a) operating system or b) commercial distribution or license issues
- A suitable GCS should be able to present the relevant data as simple as possible; rather than including the latest bells and whistles (realistic cockpit instruments, audio, etc.) the data should be presented in a comprehensible form
- The GCS should be as platform independent as possible (i.e., not be Windows-only)
I consider Labview, Flash and Google Earth to be tools/libraries that fall into the first category. Although there is nothing wrong with them since they are are nice and may be very suitable for this application, (in my very personal opinion) I believe that relying on such interfaces bring problems with them (incompatibilities with different versions, operating systems, etc.).
The current prototype of YAGCS relies on QT, OpenGL and a plotting library which is available as open source. QT was chosen due to it's nice signal-slot framework. So far it only understands the text-based telemetry stream that is generated by Jason's APM telemetry stream. The position of the UAV is continuously displayed on the map (previously generated from Google map tiles) and data in the plotting tab is updated. A logfile is also created, which can be used to later replay a flight (rewind and fast-forward are supported). An earlier version supports camera data received via a UDP socket and the current version shows roll/pitch data in a the OpenGL widget. This 3d view could later be extended to show the orientation of the plane relative to the next waypoint, etc. The plane model looks pretty crappy at the moment since I'm bad at modeling.
I would be interested in any feedback. Once I get the code cleaned up I would be also willing to share it if anybody is interested. Since I'm developing it on a linux (Ubuntu) machine I'm not quite sure what would be required to compile it on Windows but it should not be a bigger problem (the few lines of C code to access the serial port would need to be rewritten though).
Cheers, Andre
Comments
The main problem seemed to be not the tile downloading but the problem of how to figure out where a given lat, long coordinate shows up in google's coordinate system at a given zoom level. Check out this excellent website here. At the bottom of the website you'll find a python script called globalmaptiles.py that does exactly that (and more.. for example it also gives you the boundaries of the tile in lat, long coordinates which can be used later for creating the map).
After that, one "just" needs to dowload the tile (using the x,y,z google coordinates), some of the surrounding tiles and stich them of course. I used a perl script that can be found here. It needs wget for downloading and convert (from the imagemagick package) for stiching. But basically you could use any script for downloading URLs and stiching images together. Check out the google coordinate system which makes it easy to see which tiles are neighbors in the grid.
Hein: Thanks for the links, I will check them out. On first sight it seems that this is exactly what I have been looking for.
Have a look at these cross platform libraries that play well with Qt :
http://qextserialport.sourceforge.net/
http://www.boost.org/doc/libs/1_40_0/doc/html/boost_asio/overview/s...
Thanks,
Curt.
Martin: I would indeed be interested in that Serial class. I tried to find one that would be part of QT and didn't manage. Then I basically had to write a wrapper over some C functions that are not portable at all (and also otherwise messy).
Dr. Mike: This video feed was part of an experiment I did with my gumstix+USB-webcam over Ad Hoc Wifi. It wasn't also really video, more a slide show (a frame every 2 seconds or so). Because of trouble with the Wifi I postponed further experiments with that for the moment.
Ravi: Seems that you are a lot further than me on the mapping side. I also had a quick look at open-street map but then found a script somewhere for stitching google map tiles and went with these. Interesting looking GCS, I will try to read up on your earlier posts about Tremor.
..on an unrelated note: tried to edit this blog post but then it got republished again. Well, guess I still need to learn how to use this thing :)
I thought I would have to do it by myself!
I'm sure you'll like what we are doing with a friend of mine, I should talk about it pretty soon!
As for the serial, I have a Qt Serial class that may interest you. Look at your PM.
Mike.
I am curerrently working on one too. It is written in Java, and uses OpenGL (JOGL), and has distributions for windows, linux, mac, and solaris. It sources map data from one of, or from multiple, sources; google, microsoft, NASA, open street map, open bike map (high bandwidth, but fantastic). I am also trying to make the communications system totally configurable; commands are picked and linked to system functions. The platform is totally modular, so future modules can be setup and just imported in.
Totally agree with number two, dials are excessive in my opinion.
http://www.diydrones.com/forum/topics/tremor-gcs-rebuild?xg_source=...
Old before rewrite: