QG4/docs/en/qgc-dev-guide/firmware_plugin.md

# 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.
User Guide and DevGuide source migration to Stable v4_3 (#10882) * User guide migration to QGC source * Add google analytics - but need [GA4] Find your Google tag ID * Update (most) notes to use vitepress note syntax * Convert remaining notes, tips, warnings * Prettier all the files * Lower case and compress all images * Lower case filenames * docs_deploy1 * Disable platform builds on commit to docs (only) * Test deployment script 1 (#10893) * docs_deploy1 * Disable platform builds on commit to docs (only) * docs_deploy2 * lower case waypoint file * Lower case console.jpg * Add duplicate index as fallback * Get path from process * fix upload * Disable running workflows for changes in the actions * Attempt update via github workflow * Attempt workflow update * A bit more deployment debugging * MOdify yaml to use personal access token * Lower case the support.md * Fix up pattern * Add UI design - ignored by github * Fix up plugins name * Fix up toolbar * Fix up the Support path * Fix up support link to go to the NEW target * Only build this on commit * Add docs stablev4 3 (#10894) * docs_deploy1 * Disable platform builds on commit to docs (only) * docs_deploy2 * lower case waypoint file * Lower case console.jpg * Add duplicate index as fallback * Get path from process * fix upload * Disable running workflows for changes in the actions * Attempt update via github workflow * Attempt workflow update * A bit more deployment debugging * MOdify yaml to use personal access token * Lower case the support.md * Fix up pattern * Add UI design - ignored by github * Fix up plugins name * Fix up toolbar * Fix up the Support path * Fix up support link to go to the NEW target * Only build this on commit * Remove unused files 1 year ago			`# 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.`