For any normal use case where a downwards velocity setpoint is set
this works exactly the same as before.
E.g. autonomous landing, landing in Altitude or Position mode
The advantage is that the very common case where a vehicle tries
to hold a constant altitude but fails to do so e.g. during a hard brake
with too much lift the resulting downwards velocity was interpreted
as descend intent and since the vehicle already struggled to hold altitude
with low thrust and was not moving fast anymore because it was braking
this lead to a lot more false positives on certain vehicle types.
The disadvantage is that not setting a downwards velocity setpoint but
just moving the position setpoint into the ground does not result in
land detection anymore. We do not use this method of landing anymore for
quite a while. It's not recommended and I wonder if there's some rare use
case like offboard where this is done.
We could add an additional case for the specific case to land with a
position setpoint only.
The tree stages used arbitrary 350, 250 300ms totally 900ms
So this changes it to each stage to a third of the parameter.
Default it is 1 second -> 333ms per stage.
- if distance to the ground is available then hysteresis times will be increased
by a factor of 3 if vehicle is higher than 1m above ground
Signed-off-by: RomanBapst <bapstroman@gmail.com>
- the hover thrust estimate will often invalidate upon ground contact, but before the land detector ground_contact triggers
- use same time throughout call to avoid subtle timing surprises
- track and publish validity based on hover thrust variance, innovation test ratio, and hysteresis
- only publish on actual updates or becoming inactive
- fix dt (previous timestamp wasn't being saved)
- use local position timestamp (corresponding) to accel data rather than current time to avoid unnecessary timing jitter
- check local position validity before using
- mc_hover_thrust_estimator: move from wq:lp_default -> wq:nav_and_controllers to ensure the hover thrust estimator runs after the position controller and uses the same vehicle_local_position data
- land_detector: check hover thrust estimate validity and adjust low throttle thresholds if hover thrust is available
- mc_pos_control: only use hover thrust estimate if valid
- if "landed" and "maybe_landed" states are false then both the "hit_ground" and the "low_thrust" condition need to be true in order to detect landing
- ground contact MC NAN setpoint workaround
- ground contact additionally check acceleration setpoint
- schedule with vehicle_local_position updates (most updates require valid local position)
- don't allow LNDMC_Z_VEL_MAX to exceed MPC_LAND_SPEED
- ground contact horizontal movement checks default to failed if estimates aren't available
HTE runs based on the position controller so, even if we whish to use
the estimate, it is only available in altitude and position modes.
Therefore, we need to always initialize the hoverThrottle using the hover
thrust parameter in case we fly in stabilized
* MC_HTE: unitialize with hover_thrust parameter
* MC_HTE: constrain hover thrust setter between 0.1 and 0.9
* MC_HTE: integrate with land detector and velocity controller
* MCHoverThrustEstimator: Always publish an estimate even when not fusing measurements. This is required as the land detector and the position controller need to receive a hover thrust value.
* MC_HTE: use altitude agl threshold to start the estimator
local_position.z is relative to the origin of the EKF while dist_bottom
is above ground
Co-authored-by: bresch <brescianimathieu@gmail.com>
Consolidate _update_params() methods for improved inheritance from the LandDetector base class.
Move common uORB::Subscriptions to the base class for inheritance.
Deprecate redundant override methods.
- no airframe changes the default
- it does not make much sense to be able to configure the 0.1 threshold
but the 0.3 threshold for ground contact detection cannot be configured.
Before that, different modules (ekf2, commander & land detector) changed
params upon different events:
- ekf2 & commander set params after disarm
- land detector set params on land detected
If the 2 events were several 100ms appart, it led to 2 param saves, and
the latter param set could have been blocked by an ongoing save. And if
the land detector was blocked, it could lead to mag timeouts.
This patch makes all modules use the same event, thus only a single param
save will happen.
If we want to have guarantees to never block, we should introduce a
param_try_set() API method.
This commit is an attempt to fix a race condition happening on takeoff
between the land detector and the multicopter position controller.
Previously, an auto-takeoff leads to the following events:
1. A takeoff setpoint is given.
2. The thrust setpoint spikes because we don't enter smooth takeoff yet.
3. The land detector detects a takeoff because of the high thrust.
4. The position controller sees the landed state transition and
initiates the smooth takeoff. Thrust goes back down.
5. Depending on control gains the takeoff is successful or fails
if the smoothing takes too long which causes thrust to be too low, so
the land detector detects land again.
The two obvious problems with this are:
- The intermittent spike.
- The failed takeoff because of the smoothing leads to a delay..
With this change, the logic for a takeoff detection is moved from the
land detector to the position controller.
The events are now:
1. A takeoff setpoint is given.
2. The position controller detects the takeoff setpoint and initiates
the smooth takeoff.
3. As thrust ramps up, the land detector detects the take off.
In the same way, we now detect the intent to takeoff in manual,
altitude, control, position control in the position controller instead
of in the land detector.
because in altitude mode we have a baro available and can therefore check vertical movement
we can not check horizontal movement but I consider the checks for landing still pretty safe
unlike in manual mode we are not allowed to disarm before land detection in altitude mode
Matthias Grob