Sub: Rework joystick input and pilot input in general

[patrickelectric]

Moved from: bluerobotics/ardusub#158 Original author: @jaxxzer

Feature request

We need some sort of input abstraction layer that rc input and mavlink/joystick input sit on top of.

Platform [ ] All [ ] AntennaTracker [ ] Copter [ ] Plane [ ] Rover [x] Submarine

[jaxxzer]

Our inputs are limited to 4 analog axes and 16 digital buttons, this is very constraining. I would like to support an arbitrary number of analog/digital inputs with flexible assignments to things like inputs, input trims, lights channels 1, 2, 3... multiple camera gimbals, multiple manipulator joints etc.

[khancyr]

couldn't a AP_Joystick class be the solution ? like ask in https://github.com/ArduPilot/ardupilot/issues/10147 ?

[jaxxzer]

We currently have:

• Receiver input
• RC_CHANNELS
• MANUAL_CONTROL

It would be good to have some frontend abstraction that handles them all. However, there are limitations to all of these that make them unsuitable for Sub.

• They only support x number of analog and/or digital 'channels'. I would like to have any arbitrary number of inputs that can be assigned/handled.
• There is a difference in the operation of eg a two position switch, a three position switch, and a momentary button. I would like to support them all.
• The joystick buttons and 'switches' are handled on the autopilot side. This has lead to complicated parameter setups and handling in the code. I think that these things should be handled on the GCS side. QGC currently does this for other vehicles, by processing the button input and sending some MAV_CMD that the user assigns to the button. This is my preferred situation, but we need to add mavlink messages to support the button functions that we have in ArduSub.

[ES-Alexander]

Current MANUAL_CONTROL motion handling works by converting to RC overrides. This would likely be handled better by a more general abstraction (as above), but if the RC overrides conversion is kept it should at least be updated to work off parameter limits (e.g. RCn_MIN/MAX) rather than hardcoded 1100-1900 values.

This still has the issue that if a user remaps the RC channels manual control ceases to work as expected, but that seems infeasible to check for at every manual control command, and janky to update a table on update of those parameters, so is likely more of a reason for creating an underlying abstraction that can be used by all interfaces rather than another thing to patch.

[ES-Alexander]

• MAVLink MANUAL_CONTROL support was updated to 32 buttons and 6 motion axes in #25671
  • The message now also includes 6 auxiliary axes, but they are not yet mapped to functionalities in ArduSub
• The remapping and hardcoded limits issues were solved in #30788
• Migration away from autopilot handling of joystick buttons is being tracked in #28814

It remains the case that maximum counts of each peripheral type are defined with hardcoded limits, but that seems a pretty fundamental component of ArduPilot, and is likely required to avoid issues managing lots of dynamic memory allocation (which can be painful, particularly in embedded contexts). We can of course increase peripheral maximum counts and allow users to selectively enable them, but outside of that this problem seems unlikely to be addressed.