RC: Have all sticks scaled from -1 to 1 in the normalized representation

[MaEtUgR]

Currently in manual_control_setpoint which is the main normalized representation for stick input inside the firmware x, y and r are normalized to the scale -1 to 1 for full negative and positive deflection and z is scaled from 0 to 1. I can see how this might have grown historically from flying manually and having throttle directly mapped to the stick and no negative throttle being available on a plane or multicopter. But already if you fly position controlled you can go downwards and upwards with the throttle stick and it would make sense to scale it exactly like the other axes in the normalized representation.

My personal reason why I want to have all axes scaled the same is because I want to be able to substitute one axis for the other. And if you think "just rescale from one range to the other for that purpose" that doesn't work because the sensors module already calibrates directly to the different range and if you switch out sticks you have to recalibrate again.

There's another issue with calibrating throttle directly to 0 to 1 because like it's indicated in this comment
https://github.com/PX4/Firmware/blob/master/src/modules/sensors/rc_params.c#L56
the mid point of the stick for the throttle becaomes the minimum for the throttle stick calibration and if the minimum happens to be below 1000 which is not excludable then proper calibration is not possible. Also because of this value being interpreted differently depending on the mapping of the channel there's no way to just map channels without calibration.

This would all get solved by switching the throttle/z-axis to have a consistent range of -1 to 1 like all the other axes including auxiliary channels.

FYI @dagar (discussion in dev-call and slack), @LorenzMeier (discussion in the dev-call), @bkueng (discussion in person in the past),

[dagar]

We could certainly calibrate and keep the full +-1 range, but at some level we need a configuration set for the how it's to be interpreted and used, if this system is possibly even capable of negative throttle (car reverse).

What's the least bad option? Pushing more logic into the controllers to handle this, or pulling out all manual handling into a separate module (eg stick_mapper)?

Let me think about this a bit more and write down a few proposals.

[MaEtUgR]

@dagar Thanks for the in depth discussion and your comment. I still strongly suggest to allow the task/mode which consumes the stick data and generates setpoints to have full control over how to interpret them. This allows maximum flexibility and compatibility while not adding unnecessary logic. I think I'll create a pull request for what I suggest and you'll see that it's not as involved as you might think and I can assure you it simplifies matters.

[MaEtUgR]

I want to implement this together with further modularization of https://github.com/PX4/Firmware/blob/master/src/modules/sensors/rc_update.cpp to allow custom remote control parsing implementations. I think it makes even more sense then.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[junwoo091400]

Effort being continued at: #15949