In case of a diverge of the nav filter, both position and velocity test
ratios are large. If only one of them is too large, the nav filter is
most likely not diverging but is encountering a GNSS position reset and
it is still safe to fly in position mode.
Instead of directly doing the link loss reaction which by default is RTL a delay
can be configured such that the drone first switches to hold and waits
for the link to be regained.
Two sources:
1. global to local conversion was sometimes giving issues, so do everything in global
2. on startup the RTL didn't check if the home position was valid before processing it
The case when acceleration setpoints were being passed in offboard mode was triggering control_climbrate_mode. This prevented the vehicle from taking off, since it made the vehicle skip the rampup phase of the takeoff
This commit fixes this by handling the case properly
- updating the global position validity should happen regardless of
being in manual position control mode with only optical flow
- condition_global_position_valid needs to be accurate to adjudicate
main state changes (eg going into AUTO MISSION)
- split out switches from manual_control_setpoint into new message manual_control_switches
- manual_control_switches published at minimal rate (~ 1 Hz) or immediately on change
- simple switch debounce in rc_update (2 consecutive identical decodes required)
- manual_control_switches logged at full rate rather than sampled at (5-10% of messages logged)
- manual_control_setpoint publish at minimal rate unless changing
- commander handle landing gear switch for manual modes
- processing of mode_slot and mode_switch is now split so we only do one or the other (not both)
- a future step will be to finally drop mode_switch and accompanying switches entirely
Co-authored-by: Matthias Grob <maetugr@gmail.com>
- re-evaluating mode switches on altitude or position validity change can create confusing when also relying on mode changes via mavlink
- limiting this logic to only apply when disarmed solves the original problem (respecting initial switch position) without introducing potential problems mid-flight
- fixes https://github.com/PX4/PX4-Autopilot/issues/16235
- ekf2 can now run in multi-instance mode (currently up to 9 instances)
- in multi mode all estimates are published to alternate topics (eg estimator_attitude instead of vehicle_attitude)
- new ekf2 selector runs in multi-instance mode to monitor and compare all instances, selecting a primary (eg N x estimator_attitude => vehicle_attitude)
- sensors module accel & gyro inconsistency checks are now relative to the mean of all instances, rather than the current primary (when active ekf2 selector is responsible for choosing primary accel & gyro)
- existing consumers of estimator_status must check estimator_selector_status to select current primary instance status
- ekf2 single instance mode is still fully supported and the default
Co-authored-by: Paul Riseborough <gncsolns@gmail.com>
BOARD_INDICATE_ARMED_STATE was only set during arming, so an external
component might have reset the board during param save, leading to param
loss.
This extends the API to trigger the arming state also while the shutdown
lock is taken.
- drivers/tone_alarm: move to ModuleBase and purge CDev (/dev/tone_alarm0)
- drivers/tone_alarm: only run on tune_control publication (or scheduled note) rather than continuously
- drivers/tone_alarm: use HRT to schedule tone stop (prevents potential disruption)
- msg/tune_control: add tune_id numbering
- systemcmds/tune_control: add "error" special case tune_id
- move all tune_control publication to new uORB::PublicationQueued<>
- start tone_alarm immediately after board defaults are loaded to fix potential startup issues
- for SITL (or other boards with no TONE output) print common messages (startup, error, etc)
Sometimes, the mission_result timestamp is the same as the
internal_state timestamp which would meant that we would not switch to
LOITER even though the takeoff is clearly done at that point.
bresch