Fixing channel issue with ELRS Mavlink-rc: number of channels is not set by default

[msoos]

Description

If you are using ELRS MAVLINK setup as per: https://www.expresslrs.org/software/mavlink/ then the number of channels will never be set. Hence it will remain 0 -- even though there is clearly control data going through. This is because ELRS is not sending a full RC_CHANNELS packet, only channel update packets via RC_CHANNELS_RAW, to update the position of the values. Therefore, the number of channels is not set.

This ELRS system forwards BOTH the RC and the Mavlink on the same ELRS link. Using one TX and one RX, you get to have both Mavlink and RC. The Mavlink is forwarded via the backpack chip in the TX to the wifi. You can then connect to this wifi and QGC picks it up automatically, via zero-conf (I think! Very cool) and "just works". Which is great. But the RC doesn't SEEM to work, because the number of channels is never set.

TL;DR: RC_CHANNELS is never sent, only RC_CHANNELS_RAW, so chancount is never set.

Test Steps

• Using RX ELRS 3.5.0 (release version, not experimental)
• Using TX ELRS 3.5.0 (release version, not experimental)
• Using TX ELRS Backpack 1.5.0 (release version, not experimental)
• Using SpeedyBee F405 Wing (full, not mini) board, Serial 1 connected to ELRS receiver, set up as per: https://www.expresslrs.org/software/mavlink/

We get connectivity of Mavlink forwarded via ELRS + backpack in the TX via WiFi, however, the radio channels cannot be calibrated, and it cannot arm, because the number of channels is seen as 0. With this fix, calibration works and the craft can be armed.

How to Reproduce

Connect as per above. Observe that calibration is not possible, the QGC says there is no controller connected.

Checklist:

• Review Contribution Guidelines.
• Review Code of Conduct.
• I have tested my changes.

Related Issue

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[DonLakeFlyer]

This seems like a bad hack which goes against mavlink spec. Why can't whatever this system is be fixed to respect the mavlink spec? It says this:

RC_CHANNEL.channel_count - Total number of RC channels being received. This can be larger than 18, indicating that more channels are available but not given in this message. This value should be 0 when no RC channels are available.

[msoos]

Thanks for the response @DonLakeFlyer ! It turns out, they send RC_CHANNELS_OVERRIDE messages only (not _RAW). Does that change your mind regarding what should be done here?

[julled]

Thanks for looking at this proposed change! I was trying to get the described problem resolved together with @msoos .

This seems like a bad hack which goes against mavlink spec. Why can't whatever this system is be fixed to respect the mavlink spec?

https://github.com/mavlink/qgroundcontrol/blob/master/src/FirmwarePlugin/PX4/PX4ParameterMetaData.cc#L78.

RC_CHANNEL.channel_count - Total number of RC channels being received. This can be larger than 18, indicating that more channels are available but not given in this message. This value should be 0 when no RC channels are available.

As described by @msoos in the PR, the HW used here is using ELRS with mavlink msg transfer for telemetry. There the channel info is sent via mavlink messages from the RC to the FCU via ELRS. They use the RC_CHANNELS_OVERRIDE msg for this , as you can see in here:

https://github.com/ExpressLRS/ExpressLRS/blob/d68568ddd7cfea79ed3b4827b1cd70bb52f98be0/src/src/rx-serial/SerialMavlink.cpp#L35

This will overwrite the channels in ardupilot and AFAIK also PX4. The RC_CHANNELS_OVERRIDE does not contain any channel count info unfortunately and the RC_CHANNELS msg chancount is not updated.

There was a discussion on this matter in the ELRS discord that there are plans to create a new better mavlink message to account for this:

RC_CHANNELS is an output message only. There's a new message that is the "proper" way to do this but it's not stable yet.
Like, Ardu nightlies only.
https://mavlink.io/en/messages/development.html#RADIO_RC_CHANNELS

The question is now how to proceed in the meantime?

Maybe changing it to MAVLINK defined 18 instead of 16?

[DonLakeFlyer]

Hmm, that certainly is a mess.

I could live with this:

• If RC_CHANNEL.channel_count == 0 then look at the individual chan*_raw values. Count up the number of ones which are not UINT16_MAX. That should be the channel count.
• Comment all this as being a hack to support ELRS (refer to issue below in the comment)
• Create an Issue about all of this with a note to remove it once ELRS is fixed to be correct to mavlink spec

That would work?