Sub: Rework joystick input and pilot input in general

ArduPilot / ardupilot

ArduPlane, ArduCopter, ArduRover, ArduSub source

http://ardupilot.org/

GNU General Public License v3.0

10.71k stars 17.17k forks source link

Sub: Rework joystick input and pilot input in general #9808

Open patrickelectric opened 5 years ago

patrickelectric commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

jaxxzer commented 5 years ago

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 commented 2 years ago

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.