Plane/Copter: ardupilotmega's RADIO and common's RADIO_STATUS messages disagree on txbuf definition but are treated the same

[nickwithers]

[Not sure if this should be considered an ArduPilot/MAVLink issue or a MAVLink/MAVLink upstream one but feel here's the best place to start]

The "ardupilotmega" dialect defines a RADIO message with the same field names and types as the "common" RADIO_STATUS message (with a different ID).

ArduPilot appears to treat both messages the same in MAVLink handling code, e.g.: https://github.com/ArduPilot/ardupilot/blob/master/ArduCopter/GCS_Mavlink.cpp#L1283 .

In ardupilotmega against the RADIO message, txbuf is described as being How full the tx buffer is as a percentage [ https://mavlink.io/en/messages/ardupilotmega.html#RADIO , https://github.com/ArduPilot/mavlink/blob/master/message_definitions/v1.0/ardupilotmega.xml#L1236 ] and in common, the inverse (Remaining free transmitter buffer space) [ https://mavlink.io/en/messages/common.html#RADIO_STATUS , https://github.com/ArduPilot/mavlink/blob/master/message_definitions/v1.0/common.xml#L4092 ] for RADIO_STATUS.

Sending a RADIO message to ArduPilot with txbuf set to 0 to indicate, according to its description, that "the tx buffer" is 0% full leads to it throttling back messaging (see GCS_MAVLINK::handle_radio_status()).

Is the ardupilotmega description of the RADIO messages txbuf flag in need of correction? Should the RADIO and RADIO_STATUS messages be treated differently?

[peterbarker]

Oh. Whoops. That's a mess.

I've created a pair of PRs to try to start to clean it up.

We might decide at DevCall that nobody is sending "RADIO" so we can just remove it. I hope so.