How Does MAVLink Carry a Command to a Flight Controller?

• Sending and receiving computer
• Segmented message frame
• Drone exchanging messages

What you will learn

• Trace a message from a sending application to a controller and back.
• Distinguish protocol acknowledgement from task completion.
• Explain why one protocol handles telemetry and commands differently.

Before you start

No flight experience is needed. An ACK is a reply indicating that a receiver processed or recorded a request according to protocol rules.

How does a message become a command?

Software selects a message type and fills fields according to the MAVLink definition. The message is framed, given source and target identifiers, and sent over the configured channel; the receiver parses it and decides whether to process it. A router can forward messages between channels, but it cannot make a command valid under the wrong conditions.

A command exchange commonly includes a request and an ACK reply; the sender may retry if a reply does not arrive before its timeout. The ACK helps distinguish whether a command was received or rejected according to its result code. It does not always prove that a higher-level goal is complete: accepting a request to start a task is different from reporting that the task has ended. The application should keep reading the corresponding state.

Why is telemetry different from a configuration command?

MAVLink describes telemetry as data streams sent in a multicast design. Multiple receivers can observe the same message, and an old sample is often less useful than a new one. In contrast, some configuration or mission-synchronization transactions need guaranteed delivery and use point-to-point exchanges with retransmission. This lets a system apply a more reliable mechanism to operations that should not be silently lost.

“Guaranteed” here describes protocol behavior for a transaction; it does not guarantee that a radio never loses a packet or that an application chose the right command. Timeouts, reply checks and handling for an unknown outcome are still needed.

Example: acknowledge a request in a simulator

In a simulator, an application sends a parameter-read request. It records the send time, waits for an ACK or error, then checks the returned parameter value. If the timeout expires without a reply, the application marks the outcome unknown and may retry under an appropriate rule; it does not record that the value changed. Even after an ACK reports acceptance, the application waits for state or data confirming the intended result.

For a continuous setpoint, software publishes new values and observes state telemetry. A controller may accept a message type but be unable to act on it if the current mode or position data does not meet the requirement. The checks therefore include a valid message, a received response and a compatible state.

Trace faults one step at a time

If there is no reply, check whether the application created a correctly formatted message; then inspect the port and protocol, target, router and system state. If an ACK rejects the request, read its result code instead of retrying indefinitely. If an ACK accepts it but state does not change, inspect the mode, task state and input type.

MAVLink defines message exchanges; flight-stack documentation determines which commands are supported, which states they require and how they respond. A packet name alone does not establish PX4 or ArduPilot behavior.

Common misunderstandings

An ACK does not mean the task is complete. It reports a response to the request; inspect the actual result.

A syntactically valid message is not guaranteed to execute. The controller also checks whether the command fits the current state.

Frequently asked questions

Does MAVLink decide what the drone does?

No. It defines messages; the flight stack and application determine which commands are supported and when.

Is retrying a command always safe?

That cannot be assumed. The sender needs to know whether the command is safe to repeat and handle the reply before retrying.

What should I read after an ACK?

Read the task state or relevant telemetry to confirm the request reached the intended outcome.

Summary

• Software creates a message, a link carries it, and the controller replies and reports state.
• An ACK confirms protocol handling but does not necessarily confirm task completion.
• Telemetry streams and reliable transactions use different send and receive patterns.