Plugin Architecture

Although the MAVLink spec defines a standard communication protocol to communicate with a vehicle. There are many aspects of that spec that are up for interpretation by the firmware developers. Because of this there are many cases where communication with a vehicle running one firmware is be slightly different than communication with a vehicle running a different firmware in order to accomplish the same task. Also each firmware may implement a different subset of the MAVLink command set.

Another major issue is that the MAVLink spec does not cover vehicle configuration or a common parameter set. Due to this all code which relates to vehicle setup ends up being firmware specific. Also any code which must refer to a specific parameter is also firmware specific.

Given all of these differences between firmware implementations it can be quite tricky to create a single ground station application that can support each without having the codebase degrade into a massive pile of if/then/else statements peppered everywhere based on the firmware the vehicle is using.

QGC uses a plugin architecture to isolate the firmware specific code from the code which is generic to all firmwares. There are two main plugins which accomplish this FirmwarePlugin and AutoPilotPlugin.

This plugin architecture is also used by custom builds to allow ever further customization beyond when standard QGC can provide.

FirmwarePlugin

This is used to create a standard interface to parts of Mavlink which are generally not standardized.

AutoPilotPlugin

This is used to provide the user interface for Vehicle Setup.

QGCCorePlugin

This is used to expose features of the QGC application itself which are not related to a Vehicle through a standard interface. This is then used by custom builds to adjust the QGC feature set to their needs.