0

My friend and I are trying to communicate with a drone (APM 2.8 flight controller - ArduCopter V3.2.1 (36b405fb)) with MavLink. After several hours, we managed to handle messages and make ByteBuffers a little more meaningful but we're stuck on parsing one response that seems to didn’t fit with the documentation.

When performing a PARAM_REQUEST_LIST request, the APM sends back (a lot of) PARAM_VALUE (#22) responses, but the format of what we're receiving is really not what we’ve expected

The payload

<Buffer cd cc 4c 3f 32 01 36 00 45 4b 46 5f 43 48 45 43 4b 5f 54 48 52 45 53 48 09>

The expected object (doc)

PARAM_VALUE
{
    param_id    char[16]
    param_value float
    param_type  uint8_t
    param_count uint16_t
    param_index uint16_t
}

So param_id = cd cc 4c 3f 32 01 36 00 45 4b 46 5f 43 48 45 43 = ÍÌL?2(soh)6(nul)EKF_CHEC

Although the 8 last characters are OK, it seems that the first 8 characters are absolutely everything but not the beginning of a char[16] - by the way the 8th is always (nul) … And it’s the same for a param_count = 17747 when param_index = 18441 (?!), the different param_count values in every response, or param_type=82 when this value must be 0 < x <= 10 (doc)

We already managed to parse other requests without any problem so we thought we’d understood the way MavLink works but I'm doubting right now … Did we miss something obvious ? Or is there a problem with the drone ?

andrewJames
  • 19,570
  • 8
  • 19
  • 51
Pchevald
  • 1
  • 3

1 Answers1

0

For those who encountered the same problem, this page is the answer. According to this, my object looks more like that when reordered

PARAM_VALUE
{
    param_value float
    param_count uint16_t
    param_index uint16_t
    param_id    char[16]
    param_type  uint8_t
}

So param_id = 45 4b 46 5f 43 48 45 43 4b 5f 54 48 52 45 53 48 = EKF_CHECK_THRESH

Pchevald
  • 1
  • 3