* MulticopterPositionControl: Add timeout before triggering emergency setpoint on invalid TrajectorySetpoint
* Apply suggestions from code review
Co-authored-by: Jacob Dahl <37091262+dakejahl@users.noreply.github.com>
* Cleanup & address review comments
* Safegaurd against using old setpoint if states aren't valid anymore
---------
Co-authored-by: Jacob Dahl <37091262+dakejahl@users.noreply.github.com>
The default implementation for multicopter Position mode is FlightTaskManualAcceleration.
The last missing piece was support for CollisionPrevention in this implementation.
- MPC_VEL_LP: new velocity first order low pass filter (off by default)
- MPC_VEL_NF_FRQ/MPC_VEL_NF_BW: new velocity notch filter (off by default)
- MPC_VELD_LP: existing velocity derivative low pass filter, but I've dropped the remaining controllib usage
Using full 3D acceleration provides better horizontal acceleration
tracking but also creates a sometimes unwanted behavior because the tilt
is directly coupled with the vertical acceleration setpoint.
goto control class handles smoothing of goto setpoints, outputs trajectory setpoint for mc pos control
some minor encapsulation done in mc pos control for readability
new param MPC_YAWAAUTO_MAX limiting heading accelerations in heading smoother
This is a combination of the originally introduced delay:
06c10f61c1
then the emergency failsafe being changed to not just land,
position control being rescheduled to not overwrite every setpoint in:
e502214429576ce68ac3fee9d2db19112f4604b9
and it being fixed by overwriting the setpoint but not removing
the long obsolete hystersis here:
114e85d260
Because based on the numerous complaints it was disabled by default
(only velocities above 10m/s were limited)
and since then no one intentionally used it anymore. But
there were some minor investigations of drones not reaching
their maximum speed which always showed 10m/s.
- 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
- 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>
Jacob Dahl