davidbuzz's Posts (2)

Sort by

MAVProxy documentation effort and "homepage".

3689477484?profile=originalPlease be advised that MAVProxy now has a "homepage" and initial documentation effort. 

If you can add to the documentation please do.    If you find a mistake, please fix it.      If you want to complain about how poor it is to start with, I'll listen to your complaints only after you've edited more on that subject that I have.   :-)

I am not an author of mavproxy, but am doing this with the primary author's support, (Tridge)

It is located here: http://qgroundcontrol.org/mavlink/mavproxy_startpage

Read more…


I've been working on-and-off on a cross-platform GUI for mavproxy, which I've been calling "mavgui".    it's written in QT, and so will run natively anywhere where Qt will ( Mac, Android, Windows, etc ) ... and I've just started to add support in it for a "browser" window ( http://diydrones.com/profiles/blogs/browser-based-map-module-for-mavproxy) , that app would fill perfectly!   

I think I'm going to integrate these three into a GCS solution.   :-)  

My Work-in-Progress  QT based GUI is here:   https://github.com/davidbuzz/MAVProxy/tree/master/mavgui


The great thing about the mavgui I'm working on is that it's GUI is put together with a tool called "Qt Designer", and is 100% python, so it's trivial to change/tweak the layout for different use-cases like phone etc.    The Designer outputs XML, and the rest of the application is 100% python.     Here's a quick look at the XML loaded into the "Designer"....




It's not really "one giant GCS" in any sense of the word.. for a start it uses mavproxy and mavproxy modules for most of the underlying comms stuff, and everything else is just easy-to-read python.   :-)    maybe we should start a new thread for mavgui.  ?


There are a couple of parts to my experiment:  

(1)   completely separate the GUI from mavproxy, so if the GUI crashes, the mavproxy does not.

(2)  integrate with a standard mavproxy, with no changes required other than adding a "module".


"netconsole" - an underlying part of mavgui


Sending commands from the GUI "TO* mavproxy ( and hence your UAV) occurs over a tcp/ip connection to the MAV> console, by using a new mavproxy module called "netconsole".     As a bonus, you can now also use netcat, telnet,  or any other language to instruct MAVProxy.    :-)  



want to put your UAV into AUTO mode from the command line?   try this:   echo "AUTO" | nc localhost 45678

want to communicate with a Mavproxy on another machine on the LAN?  try this:    telnet otherhostip 45678 ( and you'll see a MAV> prompt, just like it was local!


using pymavlink...... another undelying part.....

There's only so much you can do with a tool like "netconsole", as I cant ( yet ) use it to communicate information about the current state of  the UAV.... so I've additionally additionally got mavproxy sending a stream of UDP packets ( --out= ) to mavgui, and using pymavlink I am displaying the latest HUD style information in the GUI.  ( like altitude, speed, gps details, etc etc ) ... most of the work here has gone into making the underlying communications system operate well, so the mavgui GUI's not yet "perfect" by any stretch of the imagination.... but it's a start.....


Just thought you'd all like to know....... :-)




Read more…