- 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
once the rampup starts. The rampup requires a valid vertical velocity setpoint.
The corner case is:
- We are before takeoff and amending the setpoint to be 0,0,100 acceleration
in order to idle
- The rampup starts BUT the setpoint is not yet overwritten by the trajectory
setpoint topic
- The idle setpoint gets amended to not contain a feed-forward vertical
acceleration because the rampup is velocity based
- The result is a brief invalid 0,0,NAN acceleration setpoint
- That invalid setpoint gets overridden by a failsafe that holds zero velocity
- Zero velocity leads to applying ~hover thrust briefly
- trajectory_setpoint and vehicle_local_position_setpoint used to be
the same data type
- we got extremely lucky here that this didn't cause any issues due to
all the fields still aligning
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
The current practice of adding topics to the default set isn't scalable,
as it affects all setups.
By making sure topics are advertised on init, logger can just discard
topics that don't exist. This does not work for all topics, so topics are
specifically marked as optional. It can be extended to more topics later
on though.
This reduces the list of topics by ~35 on a pixracer configured as quad,
and reduces RAM usage by ~1KB.
This reverts commit 446598d003.
The first warning was due to a race condition that is fixed by the previous commit;
don't omit the first warning anymore
Only modify the _setpoint for takeoff when there is a new uORB message
to avoid a race condition where both vel_sp(2) and accel_sp(2) can be
NAN at the same time.
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.
This logic was introduced to avoid large altitude drifts in velocity
mode (altitude not controlled) due to potential velocity estimate bias
in case of IMU problems (see PR #8445). After some refactorings,
the logic started to be used in altitude-controlled modes as well, which is not needed.
bresch