This is done to prevent yawing 180 degrees when switching
to hold mode with high velocity and the overshoot causing a 180°
yaw turn.
The yaw is unlocked on waypoint updates and the yaw
setpoint generation had to be put at the end because otherwise the
first yaw calculation is with the old waypoint and immediately
locks again.
When disable_weather_vane is true, the vehicle is aligning for the transition waypoint
(VTOL) and thus the yaw setpoint from Navigator should be used.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
During takeoff, Navigator is sending a constant yaw value.
However, there is always a reset at 1.5m of the yaw estimate in EKF2
that is not handled by Navigator that produces a glitch in the rate
controller. Given that in FlightTask, the yaw
is already computed and properly corrected in case of an estimator reset
event, we just ignore the yaw value sent by navigator during takeoff.
This fixes the corner case where a NAV_DELAY command changes the
validity of the next WP but not the rest of the triplet. The logic in
FlightTask was ignoring this change because the check was only based on
WP position change.
Use yawrate setpoint from weather vane only if velocity setpoint is small
(smaller than half the cruise velocity)
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
This will allow navigator to not output any setpoints while disarmed.
Otherwise the position controller outputs warnings in the form of:
Auto activation failed with error: Activation Failed
The risk here is that it could hide problems, where navigator sends invalid
triplets when it should not.
- rename of flag in position sp: from allow_weather_vane to disable_weather_vane
- flag now doesn't have to be set for all auto modes, meaning that weather vane is also active outside of mission
- flag is set before front transition to align with wp, and unset after alignment is over
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Mathieu Bresciani