joystick: migrate MANUAL_CONTROL axes to data lake

[ES-Alexander]

Relevant to #1759, per this suggestion about only needing to expose the axes.

Fixes #714:

• It doesn't provide an intuitive UI, and there are challenges around scaling, but it makes it possible
• As an example, it's possible to define numerical data-lake variables for Axis Z+ (joystick/inputs/axis-z-plus) and Axis Z-, (joystick/inputs/axis-z-minus) that then get assigned to the joystick shoulder triggers, with the values scaled and summed in the Axis Z Output compound variable (500 * ({{ joystick/inputs/axis-z-plus }} - {{ joystick/inputs/axis-z-minus }} + 1)) to provide up/down control for an ArduSub vehicle
  • I considered implementing limit and split control variables for each axis, but the scaling (and offset) functionality is vehicle-type-specific (mostly because Sub uses the wrong Z range), and I'm unsure how to implement that without causing conflicts with the values users currently control from the joystick config interface (so leaving it up to users to implement the axes they want, for now)

Enables #2221 (option 2):

• Relevant joystick axis output compound variables could be modified to have something like ({{ joystick/inputs/reverse }} ? -1 : 1) * {{ joystick/inputs/axis-x }}, which can then be controlled by the joystick and/or on-screen buttons/toggles, via the data lake and/or custom Actions
  • Implemented in joystick: add "reverse" mode and "gain" functionality #2477 - I thought it would be nicer to not review everything at once, but we can also just directly merge that instead if desired 🤷‍♂️

[ArturoManzoli]

Tested the feature based on your examples and also created some additional use cases.
It's working very well and seems to be a very useful feature that opens many possibilities.

The code changes are organized and consistent with the logic you proposed.

I might be overconcerned here, and I would like to hear @rafaellehmkuhl's opinion on this: making data lake variables (and its possible interactions with the values) be in series with manual_control inputs might work very well now, but it adds a layer of fragility to the crucial vehicle control pipeline.
Especially for aerial vehicles, having inputs pass in series through data lake variables may represent a critical failure point.

It might be worth considering making data lake–based manual_control non-standard, or having a parallel implementation so that regular manual control can act as a redundancy layer.

[ES-Alexander]

Thanks for the review @ArturoManzoli :-)

Some thoughts:

making data lake variables (and its possible interactions with the values) be in series with manual_control inputs might work very well now, but it adds a layer of fragility to the crucial vehicle control pipeline.

That is true, but I would note that the data-lake is already part of the crucial vehicle control pipeline - we already use it for which system ID to send MAVLink messages to, most Actions users create are expected to use it (including mission commands), and our dependence on it is only going to increase as we transfer telemetry-focused widgets to using it as part of source selection.

I see that more as a reason for us to make sure the data-lake infrastructure is well-tested and performant, and address any related bugs and issues quickly. It's one of the most core features of Cockpit, so if it doesn't work then Cockpit effectively doesn't work.

Especially for aerial vehicles, having inputs pass in series through data lake variables may represent a critical failure point.

Aerial vehicles can use radio control (either as the primary or as a fallback), and that seems much more robust than expecting one critical part of Cockpit to still be working when another critical part isn't.

It might be worth considering making data lake–based manual_control non-standard, or having a parallel implementation so that regular manual control can act as a redundancy layer.

I suspect this would be difficult to do without adding confusion to users (about how to use the features, and how to switch implementations in the case of one failing).

If the options can't be easily switched between live / fallen back to then it's not redundancy for an operator, just an alternative, and that would mean there's an additional critical pipeline for us to try to maintain that is supposed to do a strict subset of a different one's functionality.

I see something like a bluetooth joystick (or computer) running out of battery, or high temperature causing CPU throttling as much more likely than Cockpit's data-lake getting corrupted while still maintaining full functionality over some other part of its execution ability.

Alternative control mechanisms (like radio control, which the autopilot already treats with substantially higher priority than MAVLink) and functionality fallbacks (via autopilot failsafe mechanisms) make the risks here seem acceptable to me, and difficult to reduce in a meaningful way from within Cockpit :-)

[rafaellehmkuhl]

Will take a look at this right now.

[rafaellehmkuhl]

We discussed internally and decided to leave this PR to be merged only after the 1.18 release, as despite being a simple change, it deals with a critical pipeline (joystick controls), and we want to invest a lot on testing before we put it on a stable release.

[ES-Alexander]

Considered creating+adding a merge-after-stable label, but leaving that off for now, since we might opt to merge #2477 (still after stable) instead.