MAVLINK DOCUMENTATION HAS MOVED HERE! The remainder of this documentation is being migrated and deleted. Broken links, etc should be ignored - the content has either been moved or is no longer relevant.

MAVLink Micro Air Vehicle Communication Protocol

MAVLink Logo

MAVLink is a very lightweight, header-only message marshalling library for micro air vehicles.

It can pack C-structs over serial channels with high effiency and send these packets to the ground control station. It is extensively tested on the PX4, PIXHAWK, APM and Parrot AR.Drone platforms and serves there as communication backbone for the MCU/IMU communication as well as for Linux interprocess and ground link communication.

The MAVLink generator was first released early 2009 by Lorenz Meier under LGPL license. The generated output was always considered equal to the input message spec and has since been clarified to be MIT.

Message Specification

The current MAVLink Protocol Version can be looked up here: Common MAVLink Message Documentation

Message documentation is generated for all MAVLink messages automatically and always up-to-date. To get the details of a MAVLink message, please refer to the message lists below. You can additionally generate Doxygen API docs from the MAVLink source.

Protocol Internals

QGroundControl users: Although MAVLink itself does not rely on it, QGroundControl adjusts its views and settings based on the HEARTBEAT MAVLink message. QGroundControl uses this message also to track if a system is alive or if the connection broke. Therefore make sure to send a heartbeat every 60, 30, 10 or 1 second (1 Hz is recommended, but not required)

MAVLink Code and Generator

Instructions how to package MAVLink releases (developers only) can be found here:

MAVLink Ecosystem

There are by now many systems and software packages using MAVLink:


The MAVLink generator is LGPL licensed and its output is MIT licensed and can therefore be used as a library royalty-free in closed-source and open-source applications.

Frequently Asked Questions (FAQ)



Packet Anatomy

This is the anatomy of one packet. It is inspired by the CAN and SAE AS-4 standards.

MAVLink packet

Byte Index Content Value Explanation
0 Packet start sign v1.0: 0xFE (v0.9: 0x55) Indicates the start of a new packet.
1 Payload length 0 - 255 Indicates length of the following payload.
2 Packet sequence 0 - 255 Each component counts up his send sequence. Allows to detect packet loss
3 System ID 1 - 255 ID of the SENDING system. Allows to differentiate different MAVs on the same network.
4 Component ID 0 - 255 ID of the SENDING component. Allows to differentiate different components of the same system, e.g. the IMU and the autopilot.
5 Message ID 0 - 255 ID of the message - the id defines what the payload “means” and how it should be correctly decoded.
6 to (n+6) Data (0 - 255) bytes Data of the message, depends on the message id.
(n+7) to (n+8) Checksum (low byte, high byte) ITU X.25/SAE AS-4 hash, excluding packet start sign, so bytes 1..(n+6) Note: The checksum also includes MAVLINK_CRC_EXTRA (Number computed from message fields. Protects the packet from decoding a different version of the same packet but with different variables).

Supported data types

MAVLink supports fixed-size integer data types, IEEE 754 single precision floating point numbers, arrays of these data types (e.g. char[10]) and the special mavlink_version field, which is added automatically by the protocol. These types are available:


This protocol was totally geared towards two properties: Transmission speed and safety. It allows to check the message content, it also allows to detect lost messages but still only needs six bytes overhead for each packet.

Transmission examples

Link speed Hardware Update rate Payload Float values
115200 baud XBee Pro 2.4 GHz 50 Hz 224 bytes 56
115200 baud XBee Pro 2.4 GHz 100 Hz 109 bytes 27
57600 baud XBee Pro 2.4 GHz 100 Hz 51 bytes 12
9600 baud XBee Pro XSC 900 50 Hz 13 bytes 3
9600 baud XBee Pro XSC 900 20 Hz 42 bytes 10

Future Work / Ideas