I would like to make a new push to standardise the manual control interface for tablets and joysticks. First a brief recap why RC_CHANNELS_OVERRIDE is a bad idea: When you have set up the tablet's thumb sticks or the joystick, you have already identified all ranges and mappings. Now when using the override packet all that gets lost, and the user has to re-calibrate everything again - that's a terrible and extremely confusing user model.
Moreover, it would either require the autopilot to support two RC calibrations (one for RC, one for joystick) or it implicitly assumes a fixed mapping in the RC_CHANNELS_OVERRIDE packet, which perverts this PWM interface into a semantic interface (so essentially a worse version of the MANUAL_CONTROL message).
The other issue of that approach is that gamepads have momentary switches in contrast to radio controls. So its a completely different device. The MANUAL_CONTROL packet was a step into the right direction, but its incomplete: We somehow need to also transport the desired flight mode, as we else have to rely on COMMAND messages, which might be lost.
The best design scheme I could come up with would include these basic properties:
- A gamepad ID (in case there are multiple, either on the same link or in QGC)
- The state of the whole gamepad (N axis and buttons, for buttons state and transition (up, going down, down, going up)
- The requested flight mode (base and custom)
- Wether the gamepad is requesting control or not
- What the gamepad is trying to control: The flight controls or the gimbal
As part of that effort we might want to make sure that both PX4 and APM acknowledge commands if the ACK flag is set (PX4 does that) and that at least the shared GCS (QGroundControl) uses it by default and re-transmits commands which are not ACKed. That way you can reliably send e.g. a takeoff command.