Otherwise the flight time restriction flag gets cleared too early, before
disarming (which puts the vehicle into the previous mode and it might
take off again).
Fixes the following case:
- user intention set to X
- failsafe triggers, mode = Y
- can_run for X becomes false
- user tries to switch to X
-> need to re-evaluate can_run
Previously, it was not possible to enable forwarding of messages to/from
teh USB instance because it does not have a param for it, like the
serial instances have.
With this commit, we change the default to always set forwarding on for
the USB instance as that is likely desired.
Signed-off-by: Julian Oes <julian@oes.ch>
- from the C standard, "All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use"
Instead check if system has previously switched into LOITER to acheive the current
WP of type POSITION, and in that case stay in LOITER until altitude is reached.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Do the same as DO_REPOSITION wit only the altitude field populated
and MAV_DO_REPOSITION_FLAGS set, which means:
- switch to Loiter mode if not already in it
- set the current altitude to what is specified in the altitdue field,
keep current altitude setpoint otherwise
- keep current position setpoint
- fall back to current estimated position in case a position setpoint
is not finite
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
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>
Silvan Fuhrer