I would expect that the HSI would plot the remote waypoints. I first noticed that it didn't when it wasn't highlighting the current waypoint according to my MAV, but according to what was first retrieved from the controller. Then I noticed as I deleted missions locally they were removed from the HSI. Is there a reason why this widget doesn't follow the remote waypoints and instead follows the local ones? It also contrasts with how waypoints can be created by looking on the map as any locally-reference missions are not displayed on the HSI or the map if they're created manually only if they're pulled from the remote MAV.

From looking at the code for QGC it seems that the home position should be updated when one is received according to UAS.cc:581: emit homePositionChanged(uasId, pos.latitude, pos.longitude, pos.altitude);

From my own testing it doesn't seem as if this actually happens. Is that expected behavior?

QGroundControl can be used over a variety of wired/wireless interfaces. These interfaces will have different network parameters such as latency and may require different timeout values. Right now the mission manager doesn't allow for varying the timeout values unlike the parameter management code. This would most like be a nice addition as this value should vary depending on the application. If this is becoming too many setting for a comm link all of the "failed transmission" parameters can probably be merged into one (so rewriteTimeout and retransmissionTimeout could be merged with this new parameter).

The check in HDDisplay.cc:297 checks for if the units used for the variables are in degrees or radians, but it does it by searching the entire string, so things like "deg/s" have this default applied to them, which shouldn't happen.

Also the range provided of -180/180 doesn't make sense for radians, something like -3.14159,3.14159 would work however.

Looking at the SYS_STATUS message within the Message Inspector widget it is hard to validate the values of the onboard_control_sensors_* data fields as they're shown as uint32s. Seeing '4.29496e+09' is much harder to interpret as a bitfield than the hex equivalent '0xffffe380'.

It would be nice to explain how to add generated custom messages to qgroundcontrol.

I learned how to create custom.xml with my own messages and how to generate headers from it. But how to integrate them into QGC? Small and well commented source example would be useful too.

I had the Horizontal Situation Indicator floating above the main window. I was resizing it at the top to be taller and it tried to dock it at the top of the window. This should be avoided.

this message always appears as having a 0Hz frequency, both with the demo MAVLink file as well as with my own code that is transmitting at 1Hz and being recognized by QGC.

Uninstalling qgroundcontrol leaves C:\Program Files (x86)\qgroundcontrol around with files inside of it.

01/30/2012  01:13 PM    <DIR>          accessible
01/30/2012  01:13 PM    <DIR>          audio
01/30/2012  01:13 PM    <DIR>          bearer
01/30/2012  01:13 PM    <DIR>          codecs
01/30/2012  01:13 PM    <DIR>          files
01/30/2012  01:13 PM    <DIR>          graphicssystems
01/30/2012  01:13 PM    <DIR>          iconengines
01/30/2012  01:13 PM    <DIR>          imageformats
01/30/2012  01:13 PM    <DIR>          phonon_backend
01/30/2012  01:13 PM    <DIR>          qmltooling
01/30/2012  01:13 PM    <DIR>          sqldrivers

It also leaves the QGC entry in the start menu.

This checkbox should be moved over to under the Curve Selection list, as that's the part of the UI that it pertains to. It should also be fixed to actually show the units of each variable or be changed to say "Show datatypes", though I vote for the former as I don't see the latter as actually being useful.

MAVLinkProtocol.cc uses a two-dimensional array for storing the last received sequence number for incoming messages. This is indexed by the system ID and then the component ID. It reserves 65kB to store what is most likely a very small number of pairings. The look-up times for an array like this is very fast, but that's a lot of wasted memory.

Right now MAVLINK_MSG_ID_REQUEST_DATA_STREAM is designed to enabled/disable groups of messages and this is reflected within the QGC interface. It would be nice if this message was abstracted so that it only specified inidividual messages. The grouping of these messages can either be handled via an additional message (maybe MAVLINK_MSG_ID_REQUEST_DATA_STREAM_GROUP) or handled by the groundstation itself.

If this is handled natively in QGC through the UI then you can do things such as save a bunch of different groupings of messages that are useful for debugging different things and then switch between them as desired without having to alter the autopilot itself. The fine-grained control of data stream transmission would probably be a large benefit.

Clicking the 'Select File' button (when I already have a file loaded and in view, not sure if relevant) and then hitting Cancel gives me a "Could not open file. The file is owned by use . Is the file currently used by another program?" error.

Right-clicking on a gauge should allow you a gauge-specific menu with Remove and Edit options for this specific gauge.

I'm seeing source files with both .cpp and .cc files and a single file extension should be chosen as the standard one. Qt uses .cc everywhere so I'd suggest settling on that.
Outside of the lib source directories (where it looks like all of the code uses .cpp) the following files have been identified:

qgroundcontrol\src\comm

01/17/2012  09:05 AM               676 HexSpinBox.cpp
01/17/2012  09:05 AM                73 LinkInterface.cpp
01/17/2012  09:05 AM             4,922 XbeeLink.cpp

qgroundcontrol\src\uas

01/17/2012  09:05 AM             8,928 senseSoarMAV.cpp

qgroundcontrol\src\ui

01/17/2012  09:05 AM             4,983 SlugsPadCameraControl.cpp
01/17/2012  09:05 AM             2,327 SlugsVideoCamControl.cpp
01/17/2012  09:05 AM            16,338 XbeeConfigurationWindow.cpp

qgroundcontrol\src\ui\uas

01/17/2012  09:05 AM             6,181 UASControlParameters.cpp

Useful for debugging to output these messages to the console.

I'm using Visual Studio 2010 on Windows and there aren't any prebuilt binaries for Qt 4.8 for it, so I need to compile from source. I'd like to compile as little as possible as a full Qt compilation takes forever and I had been using configure -platform win32-msvc2010 -no-webkit -no-phonon -no-phonon-backend -no-script -no-scripttools -no-multimedia -no-qt3support -fast to compile, but it looks like WebKit is required for QGroundControl (I'd assume for the Maps widget). Is Phonon or multimedia support required also?

Having installed QGC I was looking to uninstall it. Unfortunately I couldn't find it in the list of programs to uninstall within the Control Panel. I had to manually navigate to the installation folder and uninstall it there.

mavlink_msg_named_value_float_send and mavlink_msg_named_value_int_send leadds to curves named 'value' instead of the name defined in the message

If you have a vessel that is broadcasting both a VFR_HUD message and a LOCAL_POSITION_NED/GLOBAL_POSITION_INT message (any other message that triggers a speedChanged signal), then the speed indicator in the HUD will glitch between the true speed and 0.0 as the VFR_HUD code has this 0.0 hard-coded.

I had my SYS_STATUS message indicate the proper invalid GPS and the GPS_RAW_INT message had a hard-coded 3D fix status and yet the HSI widget indicated a 3D GPS fix. Might it not be better to have it show the GPS as disabled whenever the corresponding SYS_STATUS field OR the GPS_RAW_INT field indicates disabled? In this case it is likely that there is a problem on the controller and it would be likely that the GPS unit or code is not working correctly.

Things such as the system mode, CPU load, sensor health, battery voltage and current draw are all quite useful parameters to know about and should be plottable by the real-time plotting widget by default. Ideally all of the parameters of SYS_STATUS along with base_mode and system_status from HEARTBEAT should be plottable.

At the beginning of all UASWaypointManager::send*() functions there's a check for if (!uas) .... This is fine, but then this check is done again before sending the message. I'm not certain if the uas variable can go NULL during the function execution as QGC is multithreaded I believe, but even if it does the mavlink_msg_mission_*_encode() function will actually fail anyways due to accessing properties of uas. Therefore this second check should either be moved ahead of mavlink_msg_*_encode() and wrap it and the sendMessage() and sleep calls OR it should be removed.

QGC currently only support uint32, int32, and floats although other data types are useful and already enumerated in MAV_VAR. In addition it might be nice to support a boolean data type in QGC even if it is just mapping into a UINT8.

And then delete the extra README

This struct looks like its useful for creating a central data store for all the common system parameters that are either fairly constant and used within the heartbeat message and those used in other MAVLink messages. This struct seems useless as it's not used elsewhere in the code. It also doesn't fully store all the variables used within the heartbeat and so isn't useful for persistently storing that data (for example the autopilot type).

I'd suggest either removing everything except for the system_id and component_id so that it only stores data that is common to all MAVLink messages. Then I'd also recommend changing the function calls so that they just take a pointer to this struct instead of two separate arguments.

Another suggestion is to add the autopilot type element to this struct and then have the MAVLink heartbeat message merely take a pointer to this struct as its sole argument.

It looks like qgroundcontrol.pri was written incorrectly to support MS VS2010 post-build actions. To fix this change line 435 to debug { and line 456 to release { and then copying of all support files works as expected.

Pressing any of the Set buttons when running the Radio Control widget's Calibrate feature causes QGC to crash immediately. Doesn't matter if there's a system connected or not.

If you scale the Horizontal Situation Indicator widget the GPS text at the bottom gets cutoff once it's wider than it is tall.

I've been working often with the MAVLink Message Inspector widget. Sometimes I accidentally undock it and then find it impossible to be redocked no matter where I move it within QGC when it isn't full screen. If I maximize QGC then I'm able to redock the widget just fine. If I resize the window to something that isn't maximized then I'm again unable to dock it. It doesn't matter if I undocked this widget while maximized or not.

Some variables, most commonly ones using radians or degrees, have an upper and lower limit. It would be nice if those could be specified either within MAVLink or via options and displayed in the realtime plot. The limits could be a dashed line with the same color as the actual plot line. The viewport would also not shrink to smaller than this range. This solves the issue of watching the viewport change suddenly when all negative angles disappear when viewing rudder angles.

Ideally warnings could also be specified for when variables left this range. If that was designed right it could extend to bitfields and trigger on certain flags.

The single textbox/dropdown is a confusing UI paradigm for specifying the gauge you want to create. Why not have separate inputs for each of the selection criteria? If any of this information is available from MAVLink then it can be auto-populated on variable change.

I've been testing my mission management code on my autopilot and have been looking into adding error detection to receiving mission lists. From my understanding of the mission protocol when writing a mission list the transmitter first sends a MISSION_COUNT. This should then either be followed be an ACK or a MISSION message in response where the ACK can be used to indicate an error, such as a NO_SPACE error. If I try to send too many missions to my autopilot (16) it responds with a NO_SPACE ACK message and yet QGC doesn't process this and continues to wait until it times itself out. I don't think this is correct.

When compiling QGC within VS2010 any change of a file, even one that is far down the dependency tree, requires recompilation of all source files, which seems excessive. I'm betting that qgroundcontrol.pro isn't specified properly for being translated into a Visual Studio project.

At the end of a data logging session a prompt appears to ask if you want a zero-order hold on your data. While this window is up it's unclear if it is still logging or not as the screen is still scrolling. I see two easy solution, make this a checkbox at the bottom so it's set before logging is started or stop logging as soon as the dialog appears and freeze the plotter so it's obvious that no logging is occurring.

When using the realtime plot variables many times I've often want to convert the incoming units for easier reading on the display (say radians to degrees or from 1e7 degrees to true degrees), but that's not currently possible. It would be nice if a gain and offset could be applied to incoming values, probably just for display and not for recording purposes.

Ideally this can also be extended to other types of data such as bitfields for masking off only the bits you care about.

A lot of times pressing the Refresh button in the Calibration and Onboard Parameters widget won't actually transmit a MAVLINK_MSG_ID_PARAM_REQUEST_LIST message. Pressing it again always succeeds, however. I have become accustomed to just double-clicking the Refresh button, though that's definitely not the way this should work.

The top row displays the current vehicle along with some of its status information but it isn't always clear what this information is. For example there is a distance shown to the far right that I assume is the total distance traveled by the vehicle for this run. It'd be nice if hovering over that with the mouse would provide that description. A description would also be nice for the 3 text fields displayed to the right of the vehicle name which detail the vehicle's status and mode as it isn't always clear what these single-word descriptions are supposed to mean unless you're quite familiar with MAVLink.

Another suggestion would be to remove the percentage indicator from the battery charge level display and move the voltage level into that bar. That helps to show that these two things are related and reduces the amount of space necessary for displaying it.

please provide a .deb for Linux users.

Marble is basically an open google earth. It is provided as a library and a reference application. It runs on linux. It has 2d projections and a 3d globe view. It isn't distributed with satellite imagery that has the resolution of google earth, but the imagery can be easily attained:
mkdir -p ~/.local/share/marble/maps/earth
cd ~/.local/share/marble/maps/earth
git clone git://gitorious.org/marble-restricted-maps/googlesat.git
(note that it is not distributed due to licensing issues. I am not sure how that would affect this project)
It runs faster than google maps (for me, anyway) and has support for downloading regions for offline use.

Screenshots, one of marble displaying a globe, and one of marble displaying my flying field.:
http://imgur.com/a/eV2Ps

If a serial port is removed (on Windows 7 x64) then the console gets flooded with "Access Denied" messages as if it's constantly trying to access the serial port. After so many attempts to reconnect QGC should just give up and display a status message that the serial port is dead. Maybe it could poll for it reconnecting every second or something also.

If I select data from a custom MAVLink message of mine along with any other of the standard data messages only the first datapoint will contain data from every variable and every other datapoint will contain only the custom message variables.

For example I have a MAIN_POWER message with a 'voltage' variable. If I attempt to record this variable along with the SYS_STATUS.sensors_enabled variable then I see a log like the following:

timestamp_ms    M20:MAIN_POWER.voltage  M20:SYS_STATUS.sensors_enabled  
0   2472    4294955008  
86  2472        
281 2472        
476 2472        
672 2472        
882 2467

From looking at the messages that my microcontroller receives I see that QGC double-transmits many of the messages it sends. On a fast link that causes problems with state machines if they've already transitioned. For example, with both the PARAM_REQUEST_LIST and MISSION_REQUEST_LIST after I receive the first message I respond and move on, but I'll receive a second transmission from QGC. This double-transmission isn't a big deal here, but it is once we move into the mission protocol where QGC has to request missions and it does it twice. According to the documentation an error should be thrown if a request comes in out of order, which the second request will always do. This also reveals how underspecified the parameter and mission protocols are when it comes to exception handling.

The background doesn't need to scroll when no data has been selected to be displayed. This also has the benefit of when data was being displayed and user unchecks all options, it effectively pauses the screen so they can continue to look at it.

There is no ACK message at the end of a Read Missions request from QGC to an autopilot. The spec clearly defines this as a requirement.

The 'Select System' menu is disabled when there're no MAVs currently active. Unfortunately it doesn't appear to be disabled and so users may be confused by its apparent broken-ness.

If I'm reading this widget correctly, it all unavailable sensors/control units should have a red 'NO' with a yellow cross through them. If I set onboard_control_sensors_* in SYS_STATUS all to 0 that's not the case. ATT, PXY, PZ, and YAW all stay as yellow OFF, and POS/GPS stay as a red NO but missing the yellow cross. Is this correct?

When pressing the Logging button along the status row at the top of the screen brings up a find dialog. If this dialog is canceled, the button is displayed as active even though it shouldn't be. Not sure if logging is actually enabled or just the button looks that way.