MAVLink and MAVSDK development

How MAVLink is put together

Messages are defined in XML files called dialects. common.xml holds the shared set, and autopilots add their own (ArduPilot's ardupilotmega.xml, for example). A generator turns the XML into code for many languages: header-only C libraries for embedded targets, pymavlink for Python, and others. MAVLink 2, the current version, adds larger message IDs, optional extension fields that keep old and new nodes compatible, and optional packet signing to authenticate traffic.

Every node has a system ID and a component ID, and announces itself with a HEARTBEAT message, typically once per second. Higher-level behaviour is built from small protocols on top of plain messages: the mission protocol for transferring waypoints, the parameter protocol for reading and writing settings, the command protocol (a command followed by an acknowledgement), plus file transfer, camera and gimbal protocols.

Where MAVSDK fits

MAVSDK wraps those protocols in a clean API. The core is a C++ library; wrappers for other languages, Python among them, talk to a small server process over gRPC. Plugins such as Action, Telemetry, Mission, Offboard and Param cover the common jobs: arm, take off, follow a mission, stream position, send setpoints.

It is a good fit for applications that command a vehicle at a high level and want to avoid re-implementing the mission protocol. MAVSDK is developed primarily against PX4. (TODO: confirm the current extent of MAVSDK support for ArduPilot for the features you need before relying on it.)

When to drop down to raw MAVLink

• You need messages or protocols that MAVSDK does not expose.
• You are defining your own messages for a payload or companion component.
• You are building routing or bridging software that forwards traffic between links.
• You need precise control over timing, message rates or retries.
• You are writing test, logging or replay tools, where pymavlink is often the fastest route.

Custom messages

A custom dialect is an XML file that includes an existing dialect and adds your messages. Every node that needs to understand them must be built from the same definitions, so the XML belongs in version control with a clear owner. Message IDs must not collide with the upstream dialects you include. (TODO: confirm the ID range you should reserve for your target autopilot and dialect.) If a custom message has to pass through the flight controller rather than travel directly between companion and ground station, check that the autopilot will forward messages it does not recognise.

What I check in MAVLink software

• Link-loss handling driven by heartbeats, not by assuming the connection is up.
• Commands that wait for an acknowledgement and retry, rather than fire-and-forget.
• Message rates requested explicitly instead of relying on defaults.
• Unique system and component IDs across every node.
• Signing enabled where the link is exposed to other users.
• Captured telemetry logs that can be replayed against the code in tests.