to get rid of derivative spikes when navigator is
continuously updating the yaw setpoint in the
triplet for a POI but is running at a lower rate.
The proper solution is to generate that yaw setpoint
with high rate in the flight task and have the triplet
just guid to the next waypoint at low rate.
Publishes periodically (max every 1 min) a warning if the current wind estimate
is above COM_WIND_WARN.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
to allow descending by stick for reliable land detection.
Issue:
Stick smoothing gets completely reset to state when not taken off
-> downwards velocity setpoint is gone when not taken off
-> in_descend flag of land detection is never true when not taken off
-> when landing but falling out of landing it landing detection fails
bafore taking off and landing again
Having a 2nd order low-pass filter in the derivative loop reduces
stability at low cutoff values as too much phase is lost through
the filter. Using a 1st order filter avoids this issue because its
maximum phase loss is 90 degrees instead of 180 degrees for a 2nd order
lpf.
This fixes the case where we sometimes switch to altitude control
instead of position control when RC is regained.
What happens is that we detect that the pilot wants to take over control
right when RC comes back. This means that we try to go in position
control in main_state_transition, however, we are already in position
control because we come back from the failsafe state. The result of
main_state_transition is then TRANSITION_NOT_CHANGED, and therefore we
"fall back" to altitude control even though being already in position
control would have been fine.
This fix checks the return result of main_state_transition correctly and
only reacts to TRANSITION_CHANGED and TRANSITION_DENIED but ignores
TRANSITION_NOT_CHANGED.
By default we would leave the LAND failsafe as soon as a link comes
back. With this change, we switch to the LAND failsafe like a proper
mode change, immediately disabling the failsafe as such.
This is as the same that is done for RTL in fact.
This is not optimal but a workaround for the problem where we switch out
of failsafe right on landing and then discover takeoff again and start
looping through it again and again without ever disarming.
I think it was not the best idea to use errno as a global variable to
keep track of the error code. I saw the errno change from where it was
set to where it was actually used, maybe because part of it is called in
the receive thread and part in the regular update/send() thread.
To be safe, I just created a class variable instead.
