June 10, 2020
Agenda
Status update by component/project
Roadmap, and Release discussion
Community Q&A
In-Depth discussions
Join Meeting
Meeting ID : 946 175 205
Join using your mobile/desktop
Zoom is the leader in modern enterprise video communications, with an easy, reliable cloud platform for video and audio conferencing, chat, and webinars across mobile, desktop, and room systems. Zoom Rooms is the original software-based conference...
Call in using your phone, find your local number : Zoom International Dial-in Numbers - Zoom
Component update
There was a drop in public slack channel activity around May which we can’t directly explain. Lockdown, holidays, technical problem?
Flight Testing
@rroche Will update on Slack where the testing partner selection process is standing at the moment. Currently, the developer summit is first priority.
Failure injection possible in simulation but also potentially for real world by @JulianOes . It’s for now implemented for simulation but it would be awsome to be able to use the exact same mechanism on the real vehicle. There still needs to be discussion around how to do that architecturally.
PX4:master
← PX4:pr-failure-injection
opened 12:28PM - 09 Jun 20 UTC
Work in progress to implement failure injection using MAVLink (https://github.co… m/mavlink/mavlink/pull/1331) as well as a systemcmd.
Unlike the `SIM_BLOCK_...` param this can be generic to SITL, HITL, reality.
System Architecture
OS / NuttX
For STM32H7 BDMA was added
There’s some H7 issues with the GPIO slew rate
Driver
New driver for Bosch BMI88 by @dagar
Some fixes for magnetometers that are present in Invensense chips also when they are used externally over I2C.
Sensor external I2C probe
PX4:master
← PX4:pr-sens_ext_i2c_probe
opened 02:34PM - 08 Jun 20 UTC
This is a quick idea to centralize all the optional external mags. The goal is c… onsistency between boards.
- configured with new parameter SENS_EXT_I2C_PRB
Negative current on INA226 was interpreted as error code:
PX4:master
← PX4:fix-ina226-negative-current
opened 08:58AM - 10 Jun 20 UTC
**Describe problem solved by this pull request**
One vehicle we tested can gene… rate temporary negative current draw because of active braking of the ESCs/motors. Whenever this occurred the battery was considered gone because the driver is returning negative error codes the same way as sensor measurements and therefore any negative value is considered an error.
**Describe your solution**
- `read()` just like `write()` handles the data to operate on as a parameter now and the return value is solely to report success or error. The errors get handled accordingly.
- Some general refactoring and simplifications of `collect()` function.
**Test data / coverage**
I bench tested the changes on an fmu v5x board on both power module ports.
Commander
PX4:master
← PX4:detect-missing-redundant-power-supply
opened 09:03AM - 08 Jun 20 UTC
**Describe problem solved by this pull request**
The user is unaware of a broke… n or disconnected **redundant** power module.
**Describe your solution**
A parameter specifies what the redundancy level for 5V rail supply needs to be and a check makes sure that it's available before taking off.
**Test data / coverage**
Successfully tested with two INA266s and the redundancy level `COM_POWER_COUNT` on 2 and with defaults and just INA266 or ADC power module.
**Additional context**
Wider context is a closer review of possible power supply cases e.g. https://github.com/PX4/Firmware/pull/14899
@LorenzMeier What’s the plan for the next step of Commander refactoring.
There’s a bigger plan for Navigator/state machine architecture that was broken down into smaller pieces and is very slowly executed.
Estimation
Terrain estimation fix by @bresch for the selection between using a range sensor or optical flow to estimate the distance to ground. Including unit tests to make sure it doesn’t break.
PX4:master
← PX4:pr-terrain-mask
opened 09:40AM - 03 Jun 20 UTC
I tried to split the fixes properly in different commits.
Summary of the fixe… s:
- possibility to choose the aiding sources of the terrain estimator
- ~get feedback in the log from the aiding sources currently used by the terrain estimator (will require Firmware update to actually log the data)~ edit: moved to #839
- ~fix sensor simulator that was updating the ekf faster than IMU data (this created instability of the filter in dynamic unit tests) FYI @kamilritz~ edit: moved to #838
- add unit tests for flow and range fusions in the terrain estimator
~Due to the `sensor_simulator` update rate fix, a lot of unit tests are now failing (because EKF prediction step runs slower) and I'm currently fixing them.~ edit: fixed in #838
@dagar got the basics for Multi-EKF support working on master.
PX4:master
← PX4:pr-ekf2_selector
opened 01:56AM - 13 Apr 20 UTC
**WORK IN PROGRESS**
Multi-EKF will be a focus of the v1.12 release cycle. I’m … opening this early so we can begin to identify and address the architectural changes that will need to be in place to make this viable.
### Multi-EKF Background/Motivation
WIP
Currently in PX4 most commonly supported boards have 2 or 3 IMUs that are typically different models, sometimes with wildly different output data rates, and often on the same bus, or with no synchronization mechanism. As a result our sensor hub module isn't able to effectively compare raw sensor data and "vote", so it simply selects a highest priority sensor based on a simple set of fault metrics (timeouts, stale data, etc) and passes that on to the estimator. This allows the system to continue operating if a sensor is completely lost (a hard fault), but this is actually quite rare in operation. In reality most problems encountered in typical usage are soft faults that impact navigation like high vibration (aliasing, clipping) or erratic sensor problems that still produce output.
To effectively utilize the current suite of heterogeneous IMUs to mitigate the most common real world pain points I'm proposing moving to an architecture of running (at least) one estimator per IMU.


- in multi-mode each ekf2 instance publishes
- `estimator_attitude` (vehicle_attitude)
- `estimator_local_position` (vehicle_local_position)
- `estimator_global_position` (vehicle_global_position)
- a new `ekf2_selector` module consumes all estimator_* messages, selects a primary (latching), and republishes vehicle_attitude, vehicle_local_position, vehicle_global_position
- `ekf2_selector` handles resets and deltas when switching between estimator instances
- At the moment a switch will only occur if there's a fault while another estimator instance with a better combined test ratio (vel + pos + hgt) is fault free. Opportunity to identify (and store) the best sensor combination
- sensors hub is now configurable to either provide the single highest priority IMU or publish all
- new parameter `SENS_IMU_MODE` to configure IMU output
- 0: publish all vehicle_imu instances
- 1: publish only highest priority as primary
- On F7 we can start with one estimator instance per IMU. On F4 continue as is, user configurable if desired (lots of room for optimization on F4).
### TODO:
- proper multi-module support (https://github.com/PX4/Firmware/pull/12191)
- sensor_combined kill? (migrate to vehicle_imu)
- ekf2 replay review (logging all raw data for all instances probably not a good default)
- ecl analysis script updated to be aware of multiple instances
- factor in initial sensor priorities (or kill this entire concept?)
- the initial primary/preferred IMU should probably be configurable
- preflight estimator_status (commander logic updated to only care about primary or should it check all?)
- different origins?
- each estimator instance will have a slightly different origin (or worse), does it matter or can we get away with it if resets between instances are carefully handled everywhere?
- SITL add multiple sensor instances
- sensor metadata should belong to each sensor instance, not `EKF2_*` parameters
- offsets, rotations, possibly even noise
- uORB multi-instance assumptions, we can't be sure all ekf2 publications are the same instance number. Maybe time to rethink uORB with namespaces? `estimator_status0 -> estimator/0/status`
- lockstep implications (ekf2_timestamps)
- Do we potentially need/want a separate level calibration per IMU?
- per instance parameters (EKF2_MAGBIAS_{X, Y, Z}, accel and gyro noise?)
### Future
- entire matrix of sensor combinations (more sensors module configuration)
- combine onboard AND offboard estimators (UAVCAN v1)
- testing ideas, run new and old changes side by side safely
VTOL
@JulianOes found the failsafe reaction to losing GPS in fixed-wing mode is a blind loiter towards the ground with minimal airspeed.
The future approach should be to use TECS to slowly reduce the altitude instead of descending with a fixed throttle and attitude. We need an improved architecture to allow that. @sfuhrer would be up to noting down requirements for the state machine such that we have an idea of the requirements.
opened 03:38PM - 09 Jun 20 UTC
bug
Fixed Wing 🛩️
Hybrid VTOL 🛩️🚁
Failsafe 👿
safety
**Describe the bug**
When GPS is lost during the fixedwing part of a VTOL missi… on, the plane says it is going to `fixed bank loiter`. It does so without thrust, so starts diving to keep above stall speed. This results in a "hard landing" at 13 m/s horizontal and 3 m/s vertical speed.
I would assume that by default a VTOL would either actually loiter for a while to try to regain GPS or otherwise transition back to multicopter mode and slowly descend.
It certainly should not dive like that, especially when datalink and manual control is still available.
**To Reproduce**
Steps to reproduce the behavior:
1. Use: https://github.com/PX4/Firmware/pull/15063
2. `make px4_sitl gazebo_standard_vtol`
3. Plan VTOL mission in QGC and start it.
4. Enable failure injection: `param set SYS_FAILURE_EN 1`
5. Trigger GPS lost: `failure gps off`
**Log Files and Screenshots**
https://logs.px4.io/plot_app?log=d4571b45-9472-4265-bc6c-87555e95c784
```
INFO [simulator] Waiting for simulator to accept connection on TCP port 4560
INFO [simulator] Simulator connected on TCP port 4560.
INFO [commander] LED: open /dev/led0 failed (22)
MAV_TYPE: curr: 2 -> new: 22
INFO [init] Mixer: etc/mixers-sitl/standard_vtol_sitl.main.mix on /dev/pwm_output0
INFO [mavlink] mode: Normal, data rate: 4000000 B/s on udp port 18570 remote port 14550
INFO [mavlink] mode: Onboard, data rate: 4000000 B/s on udp port 14580 remote port 14540
INFO [mavlink] mode: Onboard, data rate: 4000 B/s on udp port 14280 remote port 14030
INFO [logger] logger started (mode=all)
INFO [logger] Start file log (type: full)
INFO [logger] [logger] ./log/2020-06-09/15_20_07.ulg
INFO [logger] Opened full log file: ./log/2020-06-09/15_20_07.ulg
INFO [mavlink] MAVLink only on localhost (set param MAV_BROADCAST = 1 to enable network)
INFO [px4] Startup script returned successfully
pxh> INFO [mavlink] partner IP: 127.0.0.1
[Wrn] [Event.cc:61] Warning: Deleting a connection right after creation. Make sure to save the ConnectionPtr from a Connect call
INFO [ecl/EKF] 568000: GPS checks passed
INFO [ekf2] Mag sensor ID changed to 197388
INFO [ecl/EKF] 1792000: EKF aligned, (baro hgt, IMU buf: 18, OBS buf: 14)
INFO [ecl/EKF] 1792000: reset position to last known position
INFO [ecl/EKF] 1792000: reset velocity to zero
INFO [ecl/EKF] 5151999: reset position to GPS
INFO [ecl/EKF] 5151999: reset velocity to GPS
INFO [ecl/EKF] 5151999: starting GPS fusion
INFO [commander] ARMED by Arm/Disarm component command
INFO [navigator] Takeoff to 50.0 meters above home.
INFO [commander] Takeoff detected
pxh>
pxh>
pxh>
pxh> failure gps off
ERROR [failure] Failure injection disabled by SYS_FAILURE_EN param.
Command 'failure' failed, returned 1.
pxh> param set SYS_FAILURE_EN 1
SYS_FAILURE_EN: curr: 0 -> new: 1
pxh> failure gps off
pxh>
pxh>
pxh> WARN [commander] Failsafe enabled: no global position
INFO [commander] Failsafe mode activated
WARN [navigator] Global position failure: fixed bank loiter
WARN [ecl/EKF] 156320000: GPS data stopped
INFO [ecl/EKF] 156320000: reset position to last known position
INFO [ecl/EKF] 156320000: reset velocity to zero
WARN [ecl/EKF] 156320000: stopping navigation
pxh> commander disarm
pxh> WARN [commander] Disarming denied! Not landed
pxh>
pxh> commander disarm -f
pxh> WARN [commander] Disarming denied! Not landed
```
FYI @sfuhrer @RomanBapst
@sfuhrer Is proposing to clamp the displayed airspeed sensor in the UI because most airspeed sensors have a lower limit for the minimum measured speed and might display a slightly negative airspeed instead of 0. We need to make sure components get the real airspeed measurements while the end-user should only see strong negative airspeeds in the UI and not small negative noise. @LorenzMeier suggests to not crop the published airspeed but only filter it before displaying. There should be a flag indicating the health of the sensor and the
Fixed Wing
No updates
Multicopter
Issue flying altitude mode in the simulation was fixed.
@MaEtUgR Follow up action item to change the checks in the filter.
opened 03:04PM - 09 Jun 20 UTC
closed 08:32PM - 09 Jun 20 UTC
bug
Multirotor 🛸
Failsafe 👿
safety
**Describe the bug**
When GPS is lost while flying in POSCTL I expect the vehic… le to go into ALTCTL so that the pilot can still bring the vehicle safely back. However, what happens instead is that a blind land is initiated, even though the mode displayed in QGC is ALTCTL.
The same can be reproduced in RTL. Switching to Manual control does still work but chances are a user will not try that in time!
**To Reproduce**
Steps to reproduce the behavior:
1. Use: https://github.com/PX4/Firmware/pull/15063
2. `make px4_sitl jmavsim`
3. Takeoff and fly in POSCTL (e.g. using Joystick in QGC).
4. Enable failure injection: `param set SYS_FAILURE_EN 1`
5. Trigger GPS lost: `failure gps off`
**Log Files and Screenshots**
https://logs.px4.io/plot_app?log=8bd577fe-63ea-41da-8846-33f2fef20db5
```
pxh> param set SYS_FAILURE_EN 1
SYS_FAILURE_EN: curr: 0 -> new: 1
pxh>
pxh>
pxh> failure gps off
pxh> WARN [commander] Failsafe enabled: no local position
INFO [commander] Failsafe mode activated
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] Failsafe: blind land
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] Failsafe: blind land
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] Failsafe: blind land
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] Failsafe: blind land
WARN [ecl/EKF] 156392000: GPS data stopped
INFO [ecl/EKF] 156392000: reset position to last known position
INFO [ecl/EKF] 156392000: reset velocity to zero
WARN [ecl/EKF] 156392000: stopping navigation
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] Failsafe: blind land
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
INFO [commander] Landing detected
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] Failsafe: blind land
INFO [commander] Takeoff detected
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] PositionControl: invalid setpoints
INFO [commander] Landing detected
WARN [mc_pos_control] PositionControl: invalid setpoints
WARN [mc_pos_control] Failsafe: blind land
WARN [mc_pos_control] PositionControl: invalid setpoints
INFO [commander] DISARMED by Auto disarm initiated
INFO [commander] Failsafe mode deactivated
WARN [mc_pos_control] Position-Ctrl activation failed with error: Activation Failed
WARN [mc_pos_control] Previous flight task failed, switching to mode 1
INFO [logger] closed logfile, bytes written: 9569092
```
And here is another log out of RTL:
https://logs.px4.io/plot_app?log=95824b1d-61df-4a02-ae1b-654f9a8e40d6
FYI @MaEtUgR @dagar
MAVSDK
MAVROS / RTPS / ROS2
It was proposed a live call to the summit regarding micro-ROS and the possible migration to it in PX4.
More on micro-ROS:
@LorenzMeier We have to start using it and identify our needs to make sure it’s serving us well before we spend too much effort upfront.
@dagar Who is using ROS2?
Academia has some traction some bigger companies started to use it. There’s some light shows realized with it.
Avoidance
No updates
Simulation
@Jaeyoung-Lim realized the Typhoon mesh, model and its gimbal were all rotated by 180°. That was inverted to normal.
PX4:master
← PX4:pr-fix-typhoonh480
opened 05:22PM - 07 Jun 20 UTC
I noticed that everything including camera imu, imu, motor layout was rotated by… PI, making the model functionally working, but making it confusing to debug orientations. (Issue: https://github.com/PX4/sitl_gazebo/issues/511)
My suspicion of why this happened is given that visual mesh of the body was rotated by pi, everything was simply made to fit the visual mesh. This problem became only to attention when I was trying to add the gimbal to other models. Only the typhoon h480 was working with the gimbal and the rest of the models had the gimbal rotated by pi when it was fitted by it.
Therefore, I have rewired the internals of the Typhoon H480 so that the orientation of the vehicle is actually aligned with the link orientation.
**Note**: I noticed that each of the motors were tilted slightly as in the real vehicle, so that it has more yaw authority. However, given the change of orientation change it resulted in a loss of yaw authority therefore I made every rotor align vertically. If anybody has information of how much this should be tilted (or if this is even realistic / important) I will bring the tilts back in.
**Before PR: (Vehicle yaw = 0)**

**After PR: (Vehicle yaw = 0)**

Fixes https://github.com/PX4/sitl_gazebo/issues/511
SITL tests tailsitter fails for different reasons. This was not yet looked into.
UAVCAN
DS-015 spec still under discussion. All feedback is welcomed:
https://docs.google.com/document/d/1IweUEJ2TchAAFAkGD3zIUwvn4kwimEIPraN0a5JrbX8/edit#
Roadmap, and Release discussion
@dagar We should cut another beta.
Blocking issues:
Oneshot has some problems
Multicopter land detector discussion afterwards
Developer summit
@rroche There were a lot of registrations and content proposal submissions. Thanks to everyone participating and we’re looking forward to meeting everyone virtually. There will be more updates on the schedule.
Community Q&A
Kai Gottschalk was testing fast descend speed and the drone slowed down too late. Analyzing the log it looks like the drone slowed down to land speed but with too smoothed out setpoint generation and hence too late. Kai will create an issue and @jkflying will have a first look if there’s a simple configuration check fix.
Log: https://logs.px4.io/plot_app?log=f4db817d-90fa-419c-80e4-a32bf9067817
In-Depth discussions
Multicopter land detector
@dagar would like to discuss an issue for the release:
opened 01:24PM - 08 Oct 19 UTC
closed 05:42PM - 02 Aug 20 UTC
bug
State Estimation
I put the drone in position hold about 10m above ground. Without me doing anythi… ng it suddenly dropped quiet fast, lucky it recovered before it hit the ground (in most cases). At first I was thinking some ESC problem but I had the same issue with a different MC. Also does "actuator_controls_0_0.control[3]" and "vehicle_attitude_setpoint_0.thrust_body[2]" show that the command was for throttle was set to 0 for a very short period.
That is with firmware version 1.9.2 and on pixhawk as well as on pixhawk4 hardware the same.

related:
PX4:master
← PX4:pr-land_detector_robustness
opened 01:39PM - 28 Oct 19 UTC
I would like to figure out if this change adds any value to the community.
**… Description**
The ground contact state in the multicopter land detector, as the name suggest, tries to capture the instant when the vehicle touches the ground during a landing. It uses the following conditions for the detection:
1) There is a spread between down velocity and down velocity setpoint -> hit_ground. This assumes that either the pilot or the mission is demanding a large enough down velocity setpoint during landing. This is also the reason why you should keep pulling the throttle stick down when landing.
2) The vehicle is in a low_thrust condition which basically means that the current throttle is below a predefined threshold.
In the current implementation only one condition is necessary to trigger the ground_contact state.
This implementation requires both condition to be true at the same time.
However, if the vehicle already has landed or maybe_landed state active, then the old logic is used.
**Advantages**
- reduces changes of false ground_contact detection. A false positive will lead to the controller pulling the throttle to 0 instantly which will result in the vehicle free-falling for a split second before the free-fall detection kicks in. Some vehicles might not recover from such a situation and crash.
This is the primary reason why this logic was implemented.
**Disadvantages**
- landing detection might be slower for setups with bad land detector parameters.
I can confirm that this logic works well if the land detector is setup properly.
The main question is if this deteriorates the land detection performance for vehicles in general (because the land detection params are not setup properly.)
Looking forward to hear some opinions and to get some test results.
@PX4/testflights FYI.
opened 02:35PM - 18 Oct 19 UTC
closed 05:30AM - 02 Jun 21 UTC
bug
Multirotor 🛸
**Describe the bug**
The land detector seems to detect ground contact in Descen… d mode (RC land failsafe without GPS).
1. `vertical_movement` to be `false`: https://github.com/PX4/Firmware/blob/95dc522b99688a08402ac6462ad28f5dfd338eda/src/modules/land_detector/MulticopterLandDetector.cpp#L154
2. `hit_ground` to be `true`: https://github.com/PX4/Firmware/blob/95dc522b99688a08402ac6462ad28f5dfd338eda/src/modules/land_detector/MulticopterLandDetector.cpp#L165
This happens because the z controller only reacts slowly to the new setpoint so the z velocity down is much less than the z velocity setpoint here:
https://github.com/PX4/Firmware/blob/95dc522b99688a08402ac6462ad28f5dfd338eda/src/modules/land_detector/MulticopterLandDetector.cpp#L151-L154
One observation of the descend case is that the velocity setpoint jumps to the land speed instead of gradually reaching it like in Land (with GPS) mode.

**To Reproduce**
This is hard to reproduce in SITL because the drone seems to follow the setpoint quicker.
**Expected behavior**
It should not detect ground contact until actually landed.
**Log Files and Screenshots**
This happened in a failsafe descend test:
https://review.px4.io/plot_app?log=3104d449-dd29-473f-9055-354984ff8afa
This does **not** happen in normal landing:
https://review.px4.io/plot_app?log=2ea6423f-b232-45c9-8c40-32e775118359
More info in https://github.com/PX4/Firmware/pull/13143#issuecomment-543682487.
FYI @bresch @MaEtUgR
We’ll give @Roman ’s suggestion to require low thrust AND the velocity setpoint comparison for land detection and see if there’s negative effects on all other vehicles.
Errata and Feedback
Let me know below if I failed to capture anything the right way, and if there are any updates, or you have feedback on the call format.