* Remove euler angles from attitude setpoint message
* Remove usage of euler angles in attitude setpoint messages
This commit removes the usage of euler angles in the vehicle_attitude_setpoint messages
* Fix standard vtol
- 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
- remove deprecated actuator_controls[INDEX_FLAPS/SPOILERS/AIRBRAKES]
- use new topic normalized_unsigned_setpoint.msg (with instances flaps_setpoint
and spoilers_setpoint) to pass into control allocation
- remove flaps/spoiler related fields from attitude_setpoint topic
- CA: add possibility to map flaps/spoilers to any control surface
- move flaps/spoiler pitch trimming to CA (previously called DTRIM_FLAPS/SPOILER)
- move manual flaps/spoiler handling from rate to attitude controller
FW Position controller: change how negative switch readings are intepreted
for flaps/spoilers (considered negative as 0).
VTOL: Rework spoiler publishing in hover
- pushlish spoiler_setpoint.msg in the VTOL module if in hover
- also set spoilers to land configuration if in Descend mode
Allocation: add slew rate limit of 0.5 to flaps/spoilers configuration change
Instead of doing the flaps/spoilers slew rate limiting in the FW Position Controller
(which then only is applied in Auto flight), do it consistently over all flight
modes, so also for manual modes.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
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
Don't consider these params for vertical speed threshold,
and instead increase the default for LNDMC_Z_VEL_MAX and
use solely that one. Makes the land detector outcome more
predictable and its interal logic simpler, while the new
default tuning is resulting in about the same vz threshold
as before.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- 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
-always reset roll/pitch/yaw integrators at the same time
-reset them while waiting for launch or during FW Takeoff before Climbout
-reset wheel rate integrator only when disarmed
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Since the horizontal and vertical velocity controllers are now
decoupled, it can be that the horizontal acceleration produced by the
controller is actually greater than the desired one (by design). This
condition would actually make the ARW run "backwards", degrading the
controller performance.
I think most vehicle can safely decend with at least 1.5m/s, and having this
value too low makes Descents/Landings/RTLs unnecessary long.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
bresch