- 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.
- use proper Mavlink MAV_CMD_FIXED_MAG_CAL_YAW command for initiating magnetometer quick cal
- MAV_CMD_FIXED_MAG_CAL_YAW allows specifying the yaw and optionally latitude and longitude if the vehicle doesn't have GPS
- auto disarm when locked down was added in #14766 to prevent user confusion in regular usage, but also breaks HITL where lockdown is enabled for safety
- fixes#15686
Daniel Agar