In some cases, the fitness of the optimizer does not shrink at each
iteration, causing the "decreasing fitness check" to fail. This stops
the optimization and returns with sub-optimal, or unrealistic results.
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
-check for valid airspeed_validated (declared valid plus updated less than 1s ago)
-added param (COM_ARM_ARSP_EN) to enable/disable check for max airspeed for arming set max
airspeed limit to half of stall airspeed
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- commander preflightcheck use estimator_sensor_bias message instead of EKF state index magic number
- ekf2 publish estimated bias limits in estimator_sensor_bias
- preflightcheck only error if bias estimate exceeds half of configured limit (delete COM_ARM_EKF_AB and COM_ARM_EKF_GB parameters)
- parameter updates can be quite expensive because they trigger nearly all modules to reload all of their parameters immediately
- limit modules from updating faster than once per second
- handle saving the mag bias per sensor (across all estimator instances using that mag) in sensors/vehicle_magnetometer
- this is now saving back to the actual mag calibration CAL_MAGn_OFF{X,Y,Z}
- ekf2 reset mag mag bias on any magnetometer or calibration change
- use Kalman filter scheme to update stored mag bias parameters using all available bias estimates for that sensor
Co-authored-by: Paul Riseborough <gncsolns@gmail.com>
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
Julian Kent