Dialects & Test Definitions
Dialects
MAVLink dialects are XML definition files that define protocol- and vendor-specific messages, enums and commands.
WARNING
Dialects are not managed by this project!
- They are typically used in only one particular flight stack, and are managed by that flight stack. The XML usually includes owner information as a header comment.
- Vendor forks of MAVLink may contain XML entities that have not yet been pushed into the main repository (and will not be documented).
The dialect definitions are:
- cubepilot.xml
- ardupilotmega.xml
- matrixpilot.xml
- ASLUAV.xml
- csAirLink.xml
- storm32.xml
- icarous.xml
- AVSSUAS.xml
- uAvionix.xml
- paparazzi.xml
- ualberta.xml
- loweheiser.xml
Note that dialects may include
MAVLink-Standard Definitions or other dialects. 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.
Test Definitions
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.
- python_array_test.xml — Test XML definition file for arrays.
See Also
- MAVLink-Standard Definitions
- XSD schema
- mavlink/message_definitions - Source of all XML definition files