I don't see where this is necessary. During takeoff, the maybe landed flag should
only get cleared once system is about to takeoff, and thus well after the spool up
is complete (for which the higher thresholds are meant in this case).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
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>
- move vehicle at reset detection ekf2 -> land_detector
- ekf_unit: reduce init period
- Fake fusion is when at rest is quite strong and makes the variance reduce rapidly. Reduce the amount of time we wait before checking if the variances are still large enough.
- ekf_unit: reduce minimum vel/pos variance required after init
- Fake pos fusion has a low observation noise, making the vel/pos variances reduce quickly.
Co-authored-by:: bresch <brescianimathieu@gmail.com>
Before: in_ground_effect was always true with the default settings (LNDMC_ALT_GND =-1)
and when a distance sensor was present with valid data.
Now: default of LNDMC_ALT_GND is set to 2m by default, and if set to a negative value
then in_ground_effect is never set to true
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
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.
PR #12681 added a check to the MulticopterLandDetector::_get_maybe_landed_state() method for a valid vehicle_attitude.timstamp value to finish work in PR #9756. It was discovered that the addition of that check leaves it possible to fly in acro mode without a valid attitude and auto-disarm can engage, allowing the multicopter to fall out of the sky.
instead of the derivative of the vertical position which is
not the same value when using the ekf2 estimation.
Using the position derivative resulted in delayed landing because
the value for some reason often bumped over the theshold before
slowly converging towards zero while the velocity was within expected
accuary in all these cases.
PositionControl: update comment about the order of thrust and position
mc_pos_control: reset setpoints to NAN if required
MulticopterLandDetector: consider to be landed if vehicle is not armed
mc_pos_control: initialize landing struct with landed
mc-pos-ctrl: adjust thrust-setpoint and yaw during ground-contact/maybe-landed without capturing
that information within vehicle-local-position-setpoint topic because that information
does not belong to user intention
PositionControl: set local position/velocity setpoint to NAN if not used in the control pipeline
mc-pos-ctrl: Fill vehicle_local_position_setpoint_s structure as follow:
The message contains setpoints where each type of setpoint is either the input to the PositionController
or was generated by the PositionController and therefore corresponds to the PositioControl internal states (states that were generated by P-PID).
Example:
If the desired setpoint is position-setpoint, _local_pos_sp will contain
position-, velocity- and thrust-setpoint where the velocity- and thrust-setpoint were generated by the PositionControlller.
If the desired setpoint has a velocity-setpoint only, then _local_pos_sp will contain valid velocity- and thrust-setpoint, but the position-setpoint
will remain NAN. Given that the PositionController cannot generate a position-setpoint, this type of setpoint is always equal to the input to the
PositionController.
mc_pos_control: switch to designated initializer for landed
It's less error prone because it produces an error on every discrepancy.
- 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.
