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"
- 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>
In rare occasions asking for the protocol values after setting it returned
[0, 0]. I did not see any documentation for having to wait, but adding a
short wait period fixes it.
- 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
Beat Küng