Message field order

[Lime]

Can someone explain to a low level programmer how message fields described in documentation correlate to an actual order in which they have to be sent over mavlink?

Example, HEARTBEAT. Order, suggested by documentation:

• uint8   type
• uint8   autopilot
• uint8   base_mode
• uint32  custom_mode
• uint8   system_status
• uint8   mavlink_version

Actual order:

• uint32  custom mode
• uint8   type
• uint8   autopilot
• uint8   base_mode
• uint8   system_status
• uint8   mavlink_version

Which sounds about right since documentation mentions sorting larger fields on top and in descending order as field size become smaller. But then there's STATUSTEXT message, fields of which does not get sorted by current implementation. Actual field order same as in documentation:

• uint8     severity
• char[50]  text
• uint16    id
• uint8     chunk_seq

Why is there the need for sorting fields of most messages yet still leaving exceptions? Why sorting at all? I understand it's well established thing by now, I just see it as unnecessary complication and don't see any benefit over sending fields in a fixed defined order

[Hamish Willee]

It is explained in https://mavlink.io/en/guide/serialization.html#field_reordering

There are two types of fields. The original message orders by field size, big then small, with message definition order being used for fields of the same size. Then if you extend a message using MAVLink2 extensions, any additional fields are just added in declaration order in the XML files. So that is what is happening in STATUSTEXT - the two fields at the end are extensions.

The reason for this is explained in the docs, but basically extensions allow us to add to a message without breaking compatibility, at the cost of no protection for breaking compatibility.

[Lime]

Thank you! I totally missed out on extensions concept

I only have to support a handful of messages on my peripheral, so I can get away with treating them as rigid structures. Well, at least until something breaks compatibility. : ) Maybe you know a better way to communicate auxiliary motion control (hatches, mounts, etc.) than listening to SERVO_OUTPUT_RAW by the chance? So far it works well for me, quite flexible and allows utilization of servo outputs nonexistent in hardware.

Also, is there any place with conveniently precalculated CRC_EXTRA? Though it doesn't take long to auto-detect and save a correct one.

[Hamish Willee]

So the CRC_EXTRA is compiled into the libraries - you can find it by building a library using your message set with mavgen for your programming language of choice. The complete set for all messages in C is in https://github.com/mavlink/c_library_v2/blob/908a3910ed4070b9d08e01cbf3e467f413829f1f/all/all.h#L26 but you won't need all of that. (I don't recall the format so you'd have to work that out).

>  than listening to SERVO_OUTPUT_RAW by the chance? So far it works well for me, quite flexible and allows utilization of servo outputs nonexistent in hardware.

It depends a bit on what autopilot you're working with, and then the best place to ask is on the mavlink forum for that autopilot. 

But if it is supported https://mavlink.io/en/messages/common.html#ACTUATOR_OUTPUT_STATUS supersedes the servo message.

[Lime]

CRCS seem to match with what I found using "brute force". Thank you for pointing me to a definition, now I can copy what I need and be sure I made no mistake there.

As far as my search went, none of my autopilots (if any at all) are designed to issue commands to an external servo controller on their own, they can only pass through commands from ground station. At first I thought I could implement a servo device when I saw MAV_COMP_ID_SERVO in documentation but my best bet so far is to monitor output status messages and act upon them at the expense of latency