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.
that prevents the vehicle from crashing with invalid setpoints or
states.
This broke with #16869 when the scheduling of the position control module
and the setpoint generation got independent. The failsafe mechanism assumed
the setpoint is overwirtten by the possibly infeasible input on every loop
iteration which is not the case anymore. As a result the failsafe reset its
histeresis based on the failsafe setpoint from the last loop iteration.
Keeping the failsafe_setpoint separate solves this issue. Note that
these setpoints to the bare minimum to keep the vehicle safely in the air
and do not suffer from sideffects ignoring the EKF reset.
- handle SET_POSITION_TARGET_LOCAL_NED and SET_POSITION_TARGET_GLOBAL_INT with ORB_ID(trajectory_setpoint)
- FlightTaskOffboard not needed at all
- bypass position_setpoint_triplet entirely (start removing extraneous fields)
- simplify offboard_control_mode to map to supported control modes
Matthias Grob