MAVLink definitions files can be found in mavlink/message definitions. These can roughly be divided into:
- Standard definitions - core definitions shared by many flight stacks
- Test definitions - definitions to support testing and validation
- Dialects - protocol- and vendor-specific messages, enums and commands
The following XML definition files are considered standard/core (i.e. not dialects):
- minimal.xml - the minimum set of entities (messages, enums, MAV_CMD) required to set up a MAVLink network.
- standard.xml - the standard set of entities that are implemented by almost all flight stacks (at least 2, in a compatible way). This
- common.xml - the set of entities that have been implemented in at least one core flight stack. This
We are still working towards moving the truly standard entities from common.xml to standard.xml Currently you should include common.xml
- development.xml - XML definitions that are proposed for inclusion in the standard definitions. These are work in progress.
The following definitions are used for testing and dialect validation:
- all.xml - This includes all other XML files, and is used to verify that there are no ID clashes (and can potentially be used by GCS to communicate with any core dialect).
- test.xml - Test XML definition file.
MAVLink dialects are XML definition files that define protocol- and vendor-specific messages, enums and commands.
Vendor forks of MAVLink may contain XML entities that have not yet been pushed into the main repository (and will not be documented).
Dialects may include other MAVLink XML files, which may in turn contain other XML files (up to 5 levels of XML file nesting are allowed - see
MAXIMUM_INCLUDE_FILE_NESTING in mavgen.py). A typical pattern is for a dialect to include common.xml (containing the MAVLink standard definitions), extending it with vendor or protocol specific messages.
The dialect definitions are: