Remove the entire external yaw handler, dynamic memory allocation,
pointer passing logic. Directly instanciate the weather vane instance
in the flight tasks that support it.
Weather vane should only set a yawrate setpoint, but no yaw setpoint.
Setting it to NAN when WV is active makes sure that whatever _yaw_setpoint
is set previously (e.g. through Waypoint) is not used.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Otherwise the setpoint from weather vane is constantly overwritten by it,
even if the yaw stick is not moved.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
This fixes the issue when changing the altitude during a goto for
example, where the vehicle was going backwards and upwards to reach the
closest point to the line. Now the vehicle simply goes towards the
target waypoint.
Since the same parameter is used to generate the trajectory and to
saturate the controller, there is no additional space for the output of
the position controller once it is filled with the feedforward, letting
the altitude grow uncontrolled.
To avoid weird cases where the altitude is different enough and
the offtrack state flies to the target altitude instead of the closest
point on the track between the waypoints.
In MPC_YAW_MODE 3 (along trajectory), the flight task is asked to
produce a yaw setpoint. If the previous yaw value was NAN (e.g.: during
early takeoff), the setpoint should then be reset to the current
estimate.
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.
The both results of ?: should be of same type, and some compilers give error
on this:
" implicit conversion from 'float' to 'double' to match other result of conditional"
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
Matthias Grob