Derivation by Mathieu Bresciani:
https://github.com/Auterion/trajectory_generator

The hover thrust param also changed the thrust scaling in Stabilized mode.
However if the hover thrust is very low (e.g. below 20%), the throttle
stick input becomes very distorted.

Signed-off-by: Roman <bapstroman@gmail.com>

Signed-off-by: Roman <bapstroman@gmail.com>

is executed at any time if triplet as valid yaw waypoint

This new mode of altitude control uses terrain following when holding position and normal altitude control when moving.

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.

avoidance

With the updated mixer (#9062) it's safe to set maximum thrust to 1 (in
both cases, if MC_AIRMODE is set, or not set).
So I see no reason to limit the maximum thrust.

instantiate flight tasks and the refactored position controller class
only use the new functionality if a temporary parameter is set for testing

This reverts commit d6df692b.

The changes to attitude controller improve this a lot.

At 90 degrees the yaw is extremely unstable (tested with HIL), it
overshoots and only very slowly converges to the correct value.
This behavior is also noticable with lower angles, but not so extreme.
It definitely needs to be looked into further, but for now this makes it
safer.

mc_pos_control auto: replace min_cruise_speed with cruise_speed_90; take care of case when cruise_speed_90 is exactly in the middle of max and min

adresses:
there were setpoint twitches at the beginning and end of my smooth takeoff routine
it was to slow and not configurable
it was only available for automatic takeoff