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.

Practice

1. Which part of a MAVLink message contains the actual data being sent between drone and controller?

easy

A. Payload

B. Header

C. Checksum

D. Footer

Solution

1. Step 1: Understand MAVLink message parts

   A MAVLink message has a header, payload, and checksum. The header contains metadata, the payload contains the actual data, and the checksum verifies integrity.

2. Step 2: Identify the data container

   The payload is the part that carries the actual information or data sent between devices.

3. Final Answer:

   Payload -> Option A

4. Quick Check:

   Payload = Data part [OK]

Hint: Payload always holds the message data [OK]

Common Mistakes:

• Confusing header with data
• Thinking checksum holds data
• Assuming footer exists in MAVLink

2. Which of the following is the correct order of parts in a MAVLink message?

easy

A. Header, Payload, Checksum

B. Payload, Header, Checksum

C. Checksum, Header, Payload

D. Header, Checksum, Payload

Solution

1. Step 1: Recall MAVLink message format

   The MAVLink message starts with a header that describes the message, followed by the payload which contains the data, and ends with a checksum to verify message integrity.

2. Step 2: Match the correct sequence

   The correct sequence is Header first, then Payload, and finally Checksum.

3. Final Answer:

   Header, Payload, Checksum -> Option A

4. Quick Check:

   Order = Header -> Payload -> Checksum [OK]

Hint: Header always comes before payload and checksum [OK]

Common Mistakes:

• Swapping payload and header order
• Placing checksum before payload
• Assuming checksum is in the middle

3. Given this simplified MAVLink message structure in code:

message = {"header": {"msg_id": 24}, "payload": {"lat": 12345678, "lon": 87654321}, "checksum": 0xABCD}

What is the value of message["payload"]["lon"]?

medium

A. 0xABCD

B. 12345678

C. 87654321

D. 24

Solution

1. Step 1: Locate the payload dictionary

   The message dictionary has a key "payload" which itself is a dictionary containing "lat" and "lon" keys.

2. Step 2: Access the longitude value

   Accessing message["payload"]["lon"] retrieves the value associated with "lon" inside the payload, which is 87654321.

3. Final Answer:

   87654321 -> Option C

4. Quick Check:

   payload["lon"] = 87654321 [OK]

Hint: Payload keys hold data values, access with payload[key] [OK]

Common Mistakes:

• Accessing header instead of payload
• Confusing checksum with data
• Using wrong key names

4. Identify the error in this MAVLink message snippet:

msg = {"header": {"msg_id": 30}, "payload": {"alt": 500}, "checksum": "1234"}

Assuming checksum must be an integer, what is wrong?

medium

A. Payload key 'alt' is missing

B. Checksum is a string, should be an integer

C. Header missing 'msg_id'

D. Payload should be a string, not a dictionary

Solution

1. Step 1: Check checksum data type

   The checksum is given as a string "1234" but it should be an integer value for proper validation.

2. Step 2: Verify other parts

   The header has a valid "msg_id" and payload has the "alt" key correctly as a dictionary, so no issues there.

3. Final Answer:

   Checksum is a string, should be an integer -> Option B

4. Quick Check:

   Checksum type must be integer [OK]

Hint: Checksum must be numeric, not string [OK]

Common Mistakes:

• Ignoring checksum type
• Assuming payload keys missing
• Confusing header fields

5. You want to create a MAVLink message that sends GPS coordinates with latitude and longitude. Which structure correctly represents this message including header, payload, and checksum?

hard

A. {"header": {"msg_id": 33}, "payload": "lat=34567890, lon=98765432", "checksum": 0x1A2B}

B. {"payload": {"lat": 34567890, "lon": 98765432}, "header": {"msg_id": 33}, "checksum": 0x1A2B}

C. {"header": {"msg_id": 33}, "payload": {"lat": "34567890", "lon": "98765432"}, "checksum": "0x1A2B"}

D. {"header": {"msg_id": 33}, "payload": {"lat": 34567890, "lon": 98765432}, "checksum": 0x1A2B}

Solution

1. Step 1: Check message part order and types

   {"header": {"msg_id": 33}, "payload": {"lat": 34567890, "lon": 98765432}, "checksum": 0x1A2B} has the correct order: header, payload as a dictionary with numeric lat/lon, and checksum as a hex integer.

2. Step 2: Identify errors in other options

   {"payload": {"lat": 34567890, "lon": 98765432}, "header": {"msg_id": 33}, "checksum": 0x1A2B} has wrong order (payload before header). {"header": {"msg_id": 33}, "payload": "lat=34567890, lon=98765432", "checksum": 0x1A2B} uses payload as a string, not dictionary. {"header": {"msg_id": 33}, "payload": {"lat": "34567890", "lon": "98765432"}, "checksum": "0x1A2B"} uses strings for lat/lon and checksum, which is incorrect.

3. Final Answer:

   Correct structure with header, numeric payload, and integer checksum -> Option D

4. Quick Check:

   Correct order and types = {"header": {"msg_id": 33}, "payload": {"lat": 34567890, "lon": 98765432}, "checksum": 0x1A2B} [OK]

Hint: Header first, payload dict with numbers, checksum integer [OK]

Common Mistakes:

• Wrong order of parts
• Payload as string instead of dict
• Checksum as string instead of int