Frequently Asked Questions (FAQ)

Users

How efficient is MAVLink?

MAVLink is a very efficient protocol. MAVLink 1 has just 8 bytes overhead per packet, including start sign and packet drop detection. MAVLink 2 has just 14 bytes of overhead (27 if signing is used), but is now a much more extensible protocol.

How many vehicles does MAVLink support?

255 vehicles, with system IDs ranging from 1 to 255 (0 is not a valid vehicle ID).
Note: Strictly speaking MAVLink supports 255 concurrent systems, and these can include a mix of vehicles, GCS, antenna trackers and other hardware.

Where can I use MAVLink?

MAVLink has been shown to work on multiple microcontrollers and operating systems, including ARM7, ATMega, dsPic, STM32 and Windows, Linux, MacOS, Android and iOS.

How reliable is MAVLink?

Very. MAVLink has been used since 2009 to communicate between many different vehicles, ground stations (and other nodes) over varied and challenging communication channels (high latency/noise). It provides methods for detecting packet drops, and the well-established ITU X.25 checksum for packet corruption detection.

Developers

Can I use MAVLink in a closed source application without copyright issues?

Yes, without any limitations. The generated MAVLink library headers are made available under the *MIT license* (for more information see: Introduction > License).

How does MAVLink detect and decode messages in the byte stream?

MAVLink waits for the packet start sign, then reads the packet length and matches the checksum after n bytes. If the checksum matches, it returns the decoded packet and waits again for the start sign. If bytes are altered or lost, it will drop the current message and continue the next try on the following message.

MAVLink uses only one start sign - isn't this less safe than using two or three start signs?

No. We use the CRC check to reliably determine whether a complete message has been received. Using additional start signs may increase likelihood of detecting the start point, but would provide no greater certainty of message validity. Since extra signs would increase bytes on the communication link, we choose not to use them.

What are the system and component IDs for?

The system ID represents the identity of a particular MAVLink system (vehicle, GCS, etc.). MAVLink can be used with up to 255 systems at the same time. The component ID reflects a component that is part of a larger system - for example a system might include an autopilot, companion computer and/or camera, which can be separately addressed. The component ID therefore lets MAVLink be used for both on- and off-board communication.

Why is the sequence number in the MAVLink header needed?

MAVLink is part of the safety critical components of an unmanned air system. A bad communication link dropping many packets can endanger the flight safety of the aircraft and has to be monitored. Having the sequence in the header allows MAVLink to continuously provide feedback about the packet drop rate and thus allows the aircraft or ground control station to take action.

Why is CRC_EXTRA needed in the packet checksum?

The CRC_EXTRA CRC is used to verify that the sender and receiver have a shared understanding of the over-the-wire format of a particular message (required because as a lightweight protocol, the message structure isn't included in the payload).

In MAVLink 0.9 the CRC was not used (although there was a length check). There were a small number of cases where XML describing a message changed without changing the message length, leading to badly corrupted fields when messages were read.

I would like to help improve the decoding/encoding routines or other features. Can MAVLink be changed?

Yes, but only very, very carefully with safety testing.
MAVLink is used as a safety-critical component in many autopilot systems and has undergone many years of testing. Please suggest new features on the MAVLink support channels.