On SPM4649T receivers with firmware versions at least 1.1RC9, the
serial data will contain an rssi value in dbm, as outlined in the
Remote Receiver Interfacing document section 8.3.1.
If the value received is greater than or equal to zero, the receiver
does not support rssi data, and the incoming value will be ignored.
However, if the value is negative, we can use the rssi value.
When we have a valid rssi, it gets mapped to a percentage from 0 to
100 as expected by mavlink. This mapping is constructed as a
logarithmic function over Spektrum's published minimum and maximum
rssi values, -92dBm to -42dBm as 0 to 100:
100 Log10[1 + (x - min) * (9 / (max - min))]
This change updates all calls to the dsm input rountes to return
the rssi value.
Note that one place this doesn't work with the px4io enabled.
There is a comment left in the absence of analog rssi that:
"we do not actually get digital RSSI regs[PX4IO_P_RAW_RC_NRSSI]".
This restriction has been left in place, as removing it exposes a
problem where the frequency of the control tick is greater than
that of valid dsm frames so the rssi isn't valid every cycle.
It scales the yawspeed setpoint arbitrarily by default with 0.5.
This makes no sense because when you give a setpoint of 1rad/s then
you expect the setpoint to get executed. If you want manual yawspeed
response to be less agressive on the stick use the scaling parameter
for the stick MPC_MAN_Y_MAX.
Until now we replaced legacy position controller functionality inside
the flight task architecture to split up the huge position control
module into the different tasks and have a modular setup with a clear
setpoint interface. This commit removes all the legacy code and hard
switches to using the flight task architecture for multicopter.
This is done because maintaining and testing everything in parallel is
not sustainable. The architecture is by now tested to cover all basic
legacy functionality and missing corner cases can be fixed a lot easier
with the new architecture.
More than a year ago I started the easy to use math::Functions to handle
the always used mathematical SISO functions to be tested and available.
I switched x, y and z stick input to the freesh programmed deadzone and
exponential functions from the library to unify and clarify their use.
I just realized yaw was left over because it lead to a drift problem in
certain new use cases.
Now I'm just adding the yaw stick to the already well working method.
Paul Riseborough