This happens when BAT_CRIT_THR allows arming with a critical battery level. With this change it still fails the checks but only warns instead of doing the failsafe action because that would immediately land the vehicle before it has taken off.
Special handling for LAND mode: always allow to switch into it such that if used
as emergency mode it is always available. When triggering it the user generally wants
the vehicle to descend immediately, and if that means to switch to DESCEND it is fine.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
For many failsafes, it is possible to select RTL and Land as actions.
In this commit I synchronize the clear condition for these two action
options, to always only clear on Disarm or manual mode change.
Reasoning is that for the user RTL and Land is a similar action and
I would thus expect them to be as similar as possible. And I in general
would rather not clear a failsafe state instead of too often clearing it.
Example: GF failsafe with action Land --> even if the drone is marginally
within the GF again, I want it to proceed with the Landing unless
I manually intervene.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
We've come accross a case where a ROS node would consistently take something
over 800 ms until the first arming check request subscription callback was
triggered.
After the first sample, the callback always triggered within the expected
timeframe.
Therefore this patch allows for more time right after registration until
timing out.
battery failures can occur upon arming when the load gets sgnificant.
In that case the safest thing to do is prevent a takeoff before anything
worse happens.
- remove commander test ratio "tuning knobs" (COM_ARM_EKF_{HGT,POS,VEL,YAW})
- these are effectively redundant with the actual tuning (noise & gate)
in the estimator, plus most users have no idea why they'd be
adjusting these other than to silence an annoying preflight complaint
- remove ekf2 "PreFlightChecker" with hard coded innovation limits
- ekf2 preflight innovation flags are now simply if any active source
exceeds half the limit preflight
* estimator gps check fail flag for spoofing
* warn whenever spoofing state changes to true, use default hysteresis to completely stop fusion
* dont introduce more GPS namings, GNSS instead
* flash: exclude mantis for cuav_x7pro
We had a case where someone took off with an experimental
system with 100% RAM usage on the embedded system
without noticing. This lead to problems during flight.
Since we already have a CPU load check it seems natural
to also check the reported RAM usage.
RomanBapst