MAVLink message structure in Drone Programming - Full Explanation

Introduction

Imagine you want to send clear instructions to a drone, but the drone only understands a specific way of receiving messages. Without a common message format, the drone might get confused or miss important details. MAVLink message structure solves this by organizing data so drones and controllers can communicate reliably.

Explanation

Start-of-Frame Marker

Every MAVLink message begins with a special byte that signals the start of a new message. This helps the receiver know exactly where the message begins, even if data is coming continuously. It acts like a flag to catch attention before the actual data arrives.

The start-of-frame marker tells the receiver when a new message begins.

Payload Length

Right after the start marker, there is a byte that tells how many bytes of useful data follow. This length helps the receiver know how much data to read for this message. It prevents reading too little or too much data.

Payload length specifies the size of the actual data in the message.

Packet Sequence

Each message has a sequence number that increases with every new message sent. This helps detect if any messages were lost or received out of order. It is like numbering pages in a book to keep track of the order.

Packet sequence numbers help track message order and detect losses.

System and Component IDs

Messages include identifiers for the system (like a specific drone) and the component (like a sensor or controller) sending the message. This helps receivers know who sent the message and where it came from.

System and component IDs identify the message sender.

Message ID

Each message type has a unique ID that tells the receiver what kind of data is inside. For example, a message ID might indicate that the message contains GPS data or battery status. This helps the receiver understand how to interpret the payload.

Message ID defines the type of data contained in the message.

Payload

The payload is the main part of the message containing the actual information, like sensor readings or commands. Its size is defined by the payload length. The payload format depends on the message ID.

Payload carries the actual data or commands in the message.

Checksum

At the end of the message, a checksum is included to verify that the message was received correctly without errors. The receiver calculates the checksum again and compares it to this value to confirm data integrity.

Checksum ensures the message was received without errors.

Real World Analogy

Imagine sending a letter through the mail. You start with an envelope that has a clear stamp showing it's official mail (start-of-frame). You write how many pages are inside (payload length). You number the letter so the receiver knows the order (sequence). You include your return address and sender name (system and component IDs). You label the letter type, like 'Invoice' or 'Invitation' (message ID). Inside are the pages with the actual message (payload). Finally, you sign the letter to prove it’s authentic (checksum).

Start-of-Frame Marker → Official stamp on the envelope signaling start of the letter

Payload Length → Number of pages inside the letter

Packet Sequence → Numbering the letter to keep track of order

System and Component IDs → Sender's return address and name

Message ID → Label on the letter showing its type

Payload → The actual pages with the message content

Checksum → Sender's signature proving authenticity

Diagram

Diagram

┌───────────────┬───────────────┬───────────────┬───────────────┬───────────────┬───────────────┬───────────────┐
│ Start-of-Frame│ Payload Length│ Packet Sequence│ System ID     │ Component ID  │ Message ID    │ Payload       │
├───────────────┼───────────────┼───────────────┼───────────────┼───────────────┼───────────────┼───────────────┤
│ 1 byte        │ 1 byte        │ 1 byte        │ 1 byte        │ 1 byte        │ 1 byte        │ Variable size │
└───────────────┴───────────────┴───────────────┴───────────────┴───────────────┴───────────────┴───────────────┘
                                      ↓
                               ┌───────────────┐
                               │ Checksum (2B) │
                               └───────────────┘

This diagram shows the order and size of each part in a MAVLink message from start marker to checksum.

Key Facts

Start-of-Frame Marker → A special byte that marks the beginning of a MAVLink message.

Payload Length → A byte indicating how many bytes of data follow in the message.

Packet Sequence → A number that increases with each message to track order and loss.

System ID → An identifier for the sending system, like a specific drone.

Message ID → A unique number that defines the type of message content.

Checksum → A value used to verify the message was received without errors.

Common Confusions

Believing the payload length includes the entire message size.

Believing the payload length includes the entire message size. The payload length only counts the size of the data part, not the header or checksum.

Thinking the checksum is optional or only for encryption.

Thinking the checksum is optional or only for encryption. The checksum is mandatory and used to detect errors, not for encryption.

Assuming system ID and component ID are the same.

Assuming system ID and component ID are the same. System ID identifies the whole device, while component ID specifies a part like a sensor or controller.

Summary

MAVLink messages have a clear structure starting with a marker, followed by length, sequence, IDs, payload, and checksum.

Each part of the message helps ensure the data is understood correctly and comes from the right source.

The checksum at the end protects against errors during transmission.