MAVLink dialects are XML definition files that define protocol- and vendor-specific messages, enums and commands.
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 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 entitites that have been implemented in at least one core flight stack. This
Further, all.xml is a special case. It includes almost all other XML definition files, and can be used to verify that there are no ID clashes (and can potentially be used by GCS to communicate with any core dialect).
We are still working towards moving the truly standard entities from common.xml to standard.xml Currently you should include common.xml
Core dialects are stored in mavlink/message definitions. These are the dialects for the major MAVLink stakeholder flight stacks.
Vendor forks of MAVLink may contain dialect messages that are not yet merged, and hence will not appear in this documentation.
Human-readable forms of all the the core dialects are linked below:
MAVLink provides the /external/dialects folder for dialects from projects that are not maintained by core MAVLink stakeholders or part of the MAVLink standard.
This mechanism is provided to help non-stakeholder dialect owners avoid clashes with other dialects (and the standard), and to ease integration of generic behaviours into the standard in future. These are not managed by the core team and do not appear in this documentation.
Information about using the folder can be found in github: /external/dialects
We highly recommend that you work with the standard and core stakeholder dialects rather than using this approach (there are significant benefits in terms of compatibility and adoptability when using the standard definitions).