bluerobotics
Make `MANUAL_CONTROL` support directly configurable
Current behaviour
Joystick MANUAL_CONTROL support has opaque internals (which can make transferring between control station software options needlessly ambiguous), and cannot make full use of Cockpit's Data Lake or Actions systems.
Expected or desired behaviour
MANUAL_CONTROL support could be exposed as a default Cockpit Action based on (and triggered by?) a set of predefined compound Data Lake variables (Axis X/Y/Z/R/S/T, buttons, buttons2, etc)[^1], which could in turn be composed of values that get set nicely using the existing streamlined interface, but could also be modified manually to include other Data Lake variables (or combinations) as relevant (e.g. to allow two spring-loaded triggers to be combined as positive/negative throttle).
Having a single Action, with the standard configuration for frequency limits, and the ability to disable it, would form a decent basis for implementing #1754.
[^1]: building on #1640
Additional information
Idea raised in this comment
Prerequisites
- [x] I have checked to make sure that a similar request has not already been filed or fixed.
Technically there is no way of making a true custom control, but a semi-custom control is surly acheivable
Definitely @ES-Alexander!
I was waiting for us to merge #1794 to test this possibility again. If it works, it will be one more step in the direction of untying Cockpit to specific protocol/firmware implementations, giving more freedom to the users.
#1882 and #1883 could help with the implementation of this, although it should be minimally possible to achieve once #1658 is implemented, just somewhat awkward with some of the variable mappings, especially since there'd be no explicit link between the assigned data-lake variables and the corresponding autopilot button functions (plus the redirection that the mapping of data-lake variables to MAVLink MANUAL_CONTROL button positions would be in a compound variable, and the fact that assigning a currently unused button function type would require separately setting a parameter in the autopilot).
It could be helpful to auto-generate data-lake variables for the names of configured autopilot button functions (e.g. mmc-lights1-cycle / mmc-relay4-toggle), and provide some kind of helper tool for normal joystick configuration that handles automatically adding/removing those variables from the bitwise OR of the compound button variable(s), as well as adding/replacing the relevant autopilot parameters if a function is assigned that isn't already set to a parameter.
This will also enable/simplify a frontend-based joystick gain, which would help with the transition of ArduSub-based vehicles from using internal autopilot parameters to track and manage pilot preferences (which make more sense to tie to user profiles).
Another day, another use-case.
Inspired by this forum post, a compound variable could be set to control an axis (e.g. forward/backwards), with default behaviour to just track a joystick input, but an Action could toggle a "cruise control" mode, which would store the current axis value until cruise control is turned off.
The idea is basically a frontend version of ArduSub's "input hold set" button function, but (potentially) limited to a single axis, and expandable to support up+down trimming of the set input level with additional Actions (that could be assigned to joystick buttons or on-screen buttons / a slider).
More advanced would be to set a speed target in the autopilot (instead of a thrust target via the control station), which is potentially possible already in guided mode (I know I've spoken with Willian about enabling it, but can't remember if it's done).
Per some discord discussion, this could also serve as a basis for moving the current ArduSub parameter value integration (for the button function definitions) to be a convenience feature rather than an expectation. This would avoid unnecessary friction for firmware that uses the button bitmap to more directly determine the triggered functionality, and/or just want to use a different set of functionalities than the currently assumed ones.
That said, ArduSub is generally trying to move away from MANUAL_CONTROL button functions, as a separation of concerns between the autopilot and its mode of input (in favour of direct MAVLink messages for dedicated functionalities), so I don't think this specific idea is a high priority to put a bunch of effort into making the interface/UX nice for.