This change limits all mission items to the maximum flight altitude. The mission will still be executed and flown,
but the vehicle will never exceed the mission altitude. This ensures the vehicle can always reach the mission
items. Wether or not the entire mission should be rejected if it falls outside of the fenced area is enforced
in the mission feasibility checker function.
This commit is an attempt to fix a race condition happening on takeoff
between the land detector and the multicopter position controller.
Previously, an auto-takeoff leads to the following events:
1. A takeoff setpoint is given.
2. The thrust setpoint spikes because we don't enter smooth takeoff yet.
3. The land detector detects a takeoff because of the high thrust.
4. The position controller sees the landed state transition and
initiates the smooth takeoff. Thrust goes back down.
5. Depending on control gains the takeoff is successful or fails
if the smoothing takes too long which causes thrust to be too low, so
the land detector detects land again.
The two obvious problems with this are:
- The intermittent spike.
- The failed takeoff because of the smoothing leads to a delay..
With this change, the logic for a takeoff detection is moved from the
land detector to the position controller.
The events are now:
1. A takeoff setpoint is given.
2. The position controller detects the takeoff setpoint and initiates
the smooth takeoff.
3. As thrust ramps up, the land detector detects the take off.
In the same way, we now detect the intent to takeoff in manual,
altitude, control, position control in the position controller instead
of in the land detector.
if vmount was enabled in mavlink mode, it was continuously sending mavlink
commmands, which lead to 'command denied during calibration: 205' messages
during calibration.
If you want to go to the limit of what the vehicle can do, you need to be
able to set it so large that it is guaranteed that it's never limited by
software.
Tests showed that it's not a problem to increase it to very high numbers.
360 is too fast if you just want to hover. Next step is to add expo(),
so that we still have fine-grained control at the center and high rates
at the edges.
Previously, the yaw weight was based on the tilt angle of the attitude
setpoint (R_sp(2, 2) == cos(tilt angle)). This makes no sense, it means
the weight is low for high tilt angles even if there is no roll-pitch error
at all.
This patch changes the weight computation to be based on the tilt angle
error: the yaw weight is 1 if there is no roll-pitch error (independent
from current tilt angle), and is reduced for higher tilt angle errors.
The weight was added in 05e9a30573, without any explanation or
derivation of how and why the weight is chosen that way.
However this patch works much better in practice. The yaw control is
improved, though it can be a bit slow to converge if you do continuous &
fast roll-pitch motions (which is expected).
The feedforwarding was applied in the wrong frame: the term is given in
global coordinates, but was directly applied to body coordinates. This
patch adds the missing transformation from global to body frame.
In addition, it moves the feedforwarding before the rate limitation, so
that we cannot exceed the configured rates.
Beat Küng