Previously the condition was based on hard coded height rate estimate and
setpoint values and an altitude error threshold. That showed to be leading
to false positives when the vehicle doesn't tightly follow the altitdue
ramp given by TECS to achieve a new altitude setpoint, and has become
completely infeasibly with the latest TECS rework that leads to non-ramped
altitude setpoint changes in the tecs_status message.
The new check no longer checks the altitude error but only the height rate
instead. It begins to integrate the height rate error once it detects an
uncommanded descend condition (height rate negative while setpoint is
positive). Integral threshold can be tuned by user (VT_QC_HR_ERROR_I).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- refactor all EKF backend output predictor pieces into new OutputPredictor class
- output states are now calculated immediately with new high rate IMU rather than after EKF update
- IMU delayed sample is passed as around as control data to avoid storing an extra copy and make the requirement clear
- use `gazebo-classic` everywhere consistently referring to the original Gazebo (eg version 9,10,11)
- additional `gazebo_*` helper targets added for compatibility, but warn about deprecation and tell you the new target naming
- use `gz` everywhere when referring to Gazebo (aka Ignition Gazebo or new Gazebo)
Strictly follow the following convention for tailsitter:
FW Attitude and FW rate controller always operate in the FW frame, meaning that roll is
roll in FW, which for tailsitter means around the yaw axis in the body frame. The interfaces
between modules is though always in body frame.
That enables us to do the axis transformations for tailsitter, that are currently distributed
all over the controller (attitude, rate, vtol module), only at the input and output data of modules.
Side effect is that the FW rate control tuning gains meanings change: while before the roll gains
where meant for the body axis, they are now always applied for the FW roll axis (also in hover). So
the naming now is correct for FW, while before it was for Hover.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
This failsafe flag is currently used for not allowing to re-transition to FW, as well
as disabling pusher assist in hover. Till now it was only possible to reset it with
a commanded transition to MC, which many ground station interfaces didn't allow
as the system, after a quad-chute, already was in MC mode.
Hereby it is changed to reset when a new transition to FW is triggered (either via
RC switch or MAVLink command). It is the users responsibility to assess the situation
after a quad-chute happened to try to transition to FW again, manually proceed/land
the vehicle in MC, or let it finish the defined behavior after a quad-chute.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Benjamin Perseghetti