Multirotor landing bump detection

[breadoven]

Provides landing detection for a multirotor based on the g acceleration bump at landing and Baro altitude reaction caused by ground effect. Triggers landing detection immediately with no safety delay.

Detection is based on:

• Z axis g level exceeding 2g then falling back below 1g within 0.1s
• Baro altitude rate being -ve at the moment 2g exceeded, and < -2m/s when the g level falls back below 1g
• Throttle being below hover throttle during g spike (higher threshold used for auto throttle since it tends to be higher than manually controlled throttle when landing)

The existing landing detection will still work if the g-bump detection fails, the g-bump detection just works much more quickly.

Testing on a 5" multirotor shows it works as expected. There were no false triggers during short burst full throttle climbs which seem the most likely thing to cause false triggers. G levels can exceed 2g with these climbs but the high g level lasts longer than 0.1s. Also baro altitude rate is always +ve and the throttle is always higher than hover throttle so false triggers seem unlikely. One test result is shown in attached log file for a RTH landing.

Probably needs a lot more testing with different types/sizes of multirotors to fully understand how useful this is.

Debug 0 = landing status (high = landed), Debug 1 = Baro rate (cm/s), Debug 2 = start time g level exceeded 2g
Log timeline is between 2g being detected and landing being triggered (debug 0 high).

[Jetrell]

This is a great idea..
I was only doing some tests last week. When performing an RTH landing in a strong headwind.
This was causing the quad to bounce in the ground effect, caused by the extra lift from the headwind... Plus it also kept trying to drag itself across the ground, in attempts to make it back to the home location, while fighting the headwind... Then only after a while, did it finally disarm.

I have another suggestion, that may also aid landing and touchdown.
Its beneficial to have nav_mc_bank_angle set as high as the quad will allow for. To attain the highest forward flight speed, when auto navigating into a headwind.
But having nav_mc_bank_angle set too high, in strong windy conditions. Can cause issues in the landing descent and touchdown phase of a multirotor, when it prioritizes the acquisition of the landing coordinates, over touch-down stability.
This same issue can be seen if RTH is entered at speed, on poorly tuned quads.. The quad will apply full bank_angle and become unstable, as it attempts to turn towards home, and ascend to the RTH fly home altitude at the same time.

What do you think of having another setting nav_mc_landing_bank_angle? Default possibly set to 2/3 of the nav_mc_bank_angle.

[Jetrell]

Here is some quick tests I did today. Both are in the same clip.
Both tests were done with a 3" quad.

The 1st in the clip is without a bump. And disarms by the standard method.

The 2nd in the clip is after a bump on the landing. And disarms instantly. Noting that the only reason the second had a bump, was because it was reversing backwards into a tailwind, as it was descending (like I mention in the previous post).

Landing.bump.test.mp4

In the first flight landing test I did this day. The barometric altitude was out by 6m. And the quad hit down rather firmly, before bouncing back up into the air.. But it didn't disarm after bouncing back into the air, even with a high level of g-force and positive acceleration... Which is good to see. These tests had both nav_manual_climb_rate and nav_auto_climb_rate = 6m/s.

I was sheepish, to try a throttle up, positive acceleration test in RTH. With both those value cranked up to full. Which is 20m/s. That may certainly exceed 2g on most powerful quads.. And until #8736 is complete.. I don't want risk the chance of the quad disarming at a great height, with no way to rearm it.

[breadoven]

The first attempt at landing in the test above didn't trigger because the G bump was only 1.4 or so. It triggered on the second landing. This is normal for this quad. Usually takes 4 or more bounces. Not sure why other than the Baro is more sensitive. Other quads I've seen seem to settle first time during a RTH landing. The other thing that happened every time I did a RTH landing was the quad flipped over at the point of disarm. Didn't happen if you did a manual landing in Acro though, just landed and disarmed immediately with no fuss. Odd.

A log would be useful for this 3" quad landing @Jetrell just to compare the G and Baro behaviour with the 5".

[Jetrell]

I did 4 flights this day.. The two in the clip were 3 and 4.
In the 1st flight of the day, the baro was showing the altitude to be greater than the actual.. Which often happens with this quad.. Its FC has a DPS310 which often drifts on the first boot-up. And stabilizes every boot-up after... Unfortunately this was the flight that it bounced back up into the air, after a hard touch down(Z g of 7.99).

I've never found out why a flash logger only records the first flight, with one file. While an SD logger records multiple files of each flight.

When this FC's barometric altitude calibrates correctly and it gives a precise reading. This quad always lands very softly. And almost never bounces, unless there is some wind (as in the second clip when your bump detector worked). Which is the biggest advantage of the feature IMO.
The soft landing is due to the setting being fine tuned, to suit this quad.
nav_land_maxalt_vspd = 450
nav_land_slowdown_maxalt = 600
nav_land_slowdown_minalt = 180
nav_land_minalt_vspd = 50
nav_mc_hover_thr = 1265
airmode_throttle_threshold = 1280
throttle_idle = 3.000

I'm not sure if you can make anything of this.. debug_mode = landing But the traces don't show up like yours.

For clarity. This the first flight in the video clip. When it didn't bounce.

[stronnag]

_I've never found out why a flash logger only records the first flight, with one file. While an SD logger records multiple files of each flight.

Flash loggers typically provide multiple logs in a single file.

[DzikuVx]

@breadoven do you think we can merge that after conflicts are resolved?

[breadoven]

@breadoven do you think we can merge that after conflicts are resolved?

I don't see why it can't be merged. I did think it might benefit from having the option added to turn it off just in case it causes problems with certain setups.

[b14ckyy]

Now that FW have a proper Automatic landing System that can be commonly used, what do you think about extending this to FW as well? @Jetrell pointed me at this. He suggested that for FW a X-Bump detection might be added as well for reliable detection.

FW Autoland should typically cut throttle during the glide phase already before touchdown but an additional safety net to prevent a burned ESC or motor would be nice, just in case an altitude error causes some litho-braking.