Current Behavior
It appears that INAV is much progressing its MAVLink support, which is great to see. As regards sending RC data to an INAV FC via MAVLink, it seems however to rely on RC_CHANNELS_OVERRIDE. I propose to also support RADIO_RC_CHANNELS.
Let me say that my knowledge about INAV is very limited, I have briefly checked the current code and also issues and PRs, but given my inknowledge I may be totally wrong and this issue might in fact be obsolete. If so, may appologies and pl close immediately :)
Desired Behavior
Support of RADIO_RC_CHANNELS
Suggested Solution
Adding code to support RADIO_RC_CHANNELS
Who does this impact? Who is this for?
This is for all users of INAV which consider using MAVLink as primary protocol
Additional context
This is important to fully understand:
RC_CHANNELS_OVERRIDE is (and always had been) intended to be send by a ground control station to the vehicle, to take over RC control from e.g. a "traditional" RC link, represented by a receiver on the vehicle. However, in lack of alternative MAVLink messages, RC_CHANNELS_OVERRIDE has seen much miss-use in the recent decade. The conceptual & logical clash has a little while back been resolved by the introduction of RADIO_RC_CHANNELS, which is dedicatedly (and only!) intended to be send from a receiver on the vehicle to components on the vehicle (e.g. the FC). The component on the vehicle sending RADIO_RC_CHANNELS may be called a "MAVLink receiver". So, very simple: RC_CHANNELS_OVERRIDE (only) from ground to vehicle, RADIO_RC_CHANNELS (only) on vehicle.
I don't know if INAV supports two uart ports using MAVLink; if not, the typical usage would be with radio links which can transport both serial MAVLink and RC data. The receiver should then send RADIO_RC_CHANNELS, and must not send RC_CHANNELS_OVERRIDE.
If you want some authorative statements, I can cite two recent ones by Peter Barker, a lead dev of the ArduPilot project:
Current Behavior
It appears that INAV is much progressing its MAVLink support, which is great to see. As regards sending RC data to an INAV FC via MAVLink, it seems however to rely on RC_CHANNELS_OVERRIDE. I propose to also support RADIO_RC_CHANNELS.
Let me say that my knowledge about INAV is very limited, I have briefly checked the current code and also issues and PRs, but given my inknowledge I may be totally wrong and this issue might in fact be obsolete. If so, may appologies and pl close immediately :)
Desired Behavior
Support of RADIO_RC_CHANNELS
Suggested Solution
Adding code to support RADIO_RC_CHANNELS
Who does this impact? Who is this for?
This is for all users of INAV which consider using MAVLink as primary protocol
Additional context
This is important to fully understand:
RC_CHANNELS_OVERRIDE is (and always had been) intended to be send by a ground control station to the vehicle, to take over RC control from e.g. a "traditional" RC link, represented by a receiver on the vehicle. However, in lack of alternative MAVLink messages, RC_CHANNELS_OVERRIDE has seen much miss-use in the recent decade. The conceptual & logical clash has a little while back been resolved by the introduction of RADIO_RC_CHANNELS, which is dedicatedly (and only!) intended to be send from a receiver on the vehicle to components on the vehicle (e.g. the FC). The component on the vehicle sending RADIO_RC_CHANNELS may be called a "MAVLink receiver". So, very simple: RC_CHANNELS_OVERRIDE (only) from ground to vehicle, RADIO_RC_CHANNELS (only) on vehicle.
I don't know if INAV supports two uart ports using MAVLink; if not, the typical usage would be with radio links which can transport both serial MAVLink and RC data. The receiver should then send RADIO_RC_CHANNELS, and must not send RC_CHANNELS_OVERRIDE.
If you want some authorative statements, I can cite two recent ones by Peter Barker, a lead dev of the ArduPilot project: