ezLanding

[ctzsnooze]

A possible method to reduce 'bounce aggression' on landing, facilitate perching, retain throttle control on unexpected 'fly to the moon on arming' events, etc, with little negative impact on normal flight.

Limits motor output to not exceed the set ez_landing_limit when all sticks are centred and zeroed. Smoothly restores motor output limit when any stick, including throttle, is more than ez_landing_threshold percent away from centre/zero.

Applications:

• smoother, bounce-free landings
• tricks like 'perching' on objects
• cut motor output during flyaways without having to disarm
• (possibly) un-stick a ducted quad (whoop) from a wall just by centring sticks and cutting throttle

A 'fly to the moon on arming' problem is usually due to extreme resonance while airmode is on, effectively sending 50% throttle to the motors via the PIDs and airmode. With this PR, cutting throttle to zero and entering sticks would stop the climb to the moon, which may be better than having to disarm. However I'm not sure that this is a big thing; there will be very little control like this, and it will fall anyway. However it won't get so high and may help resolve the issue before it gets out of hand.

Whoops get stuck on a wall by PIDs and airmode attempting to push some motors quite hard to restore normal attitude. With this PR, just by centering sticks and cutting throttle, the whoop should fall off the wall and be immediately recoverable.

Testing and Tuning
To test it, flash the hex and try to take off and land, comparing how much it bounces to normal. Then see if it wrecks anything, eg in situations other than landing, where you'd normally have zero throttle and all sticks centred.

Default is strongly ON, with a limit of 10%, and a threshold of 20%. Higher values, eg limit of 20% or close to hover throttle, and threshold of 25-30% could be tested.

If threshold is set to 0, the code is 'bypassed' or 'turned off'.

For battery-below designs, which are unstable without some reasonable motor authority, a motor output limit of 10% on arming may not be sufficient to hold attitude after arming, and the ideal value would be just sufficient to barely keep the machine stable.

Possible drawback and problems:

• Hard throttle chops, with all sticks centred, eg in straight-line flying, WILL BECOME UNSTABLE with this PR. The quad will have much less authority than normal unless some residual 'idle up' on the throttle is retained.
• iTerm will accumulate during the low motor output period, so in the above setting, there may be a wobble as the accumulated iTerm is removed.
• yaw position is included in the stick check on landing, so if you cut throttle but accidentally have some residual yaw, the motors may not get limited to the minimum you've set.
• All sticks must be dead centre, and throttle must be fully at zero, to get full motor output limiting on landing. If throttle is 'on the way down' but not actually zero, then you may bounce a bit until you get it to zero.

Idle Up
Keeping throttle above the threshold of 20% during active moves - the old "idle up" method - will bypass this code and ensure 100% normal authority at all times.

If you encounter some 'negative' effect, eg instability after a throttle chop to zero in fast flight, or perhaps a wobble at the end of a flip or roll, repeat the move with some 'idle up' on your throttle.

Questions:

• Anyone have a better name for this function?
• May cause bad problems for 3D quads?
• More efficient ways to code it?
• Not a big flash consumer, should all this be inside #IFDEF

Replaces #11927 which has been closed.

Replaced by #13488, which uses a thresholded PID based method with less interference to flight during zero throttle drops.

[blckmn]

AUTOMERGE: (FAIL)

• github identifies PR as mergeable -> FAIL
• assigned to a milestone -> FAIL
• cooling off period lapsed -> PASS
• commit count less or equal to three -> PASS
• Don't merge label NOT found -> FAIL
• at least one RN: label found -> PASS
• Tested label found -> FAIL
• assigned to an approver -> PASS
• approver count at least three -> FAIL

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within a week.

[sugaarK]

Silence @git_bot

[themeadery]

I've resorted to hand catching my landings all the time because landing is so bad with airmode on. I've seen people assign a switch to airmode, but that seems silly to me and I've never even tested it to see if it works.

It would be nice to be able to smoothly land like you describe, but I have issues with the potential problems. I throttle chop aggressively all the time. You mentioned there would be some "idle up" required to combat this. Would dynamic idle take care of this though?

Landing at 0% throttle would be a big issue. If you are trying to land smoothly then you will not be anywhere near 0% throttle as you touch down. You would have to do a hard throttle chop above the ground, which would probably defeat the whole purpose of software making the quad land smoothly. Also, you mentioned the other stick needs to be dead center also. Wait, that's going to be really hard, too. As you are landing you are constantly correcting. Wind, ground effect, instability, trying to vector to a hover from the direction you were traveling, etc. That seems like a tall order to just let go of all pitch and roll inputs to land, unless you were in Angle/Horizon mode I guess. Maybe there is something I am not understanding here.

I have to say it, DJI completely nailed the landing code. It is so perfect it boggles my mind. I know they have the luxury of programming it for one specific set of hardware and weight, versus BF needing to work on all combinations of hardware, and they have downward facing sensors, but still. It is buttery. I always wanted to get a peek at the code they are using for that.

[sugaarK]

Pretty sure they use sonar as well

[github-actions]

Do you want to test this code? Here you have an automated build:
Assets
WARNING: It may be unstable. Use only for testing! See: https://www.youtube.com/watch?v=I1uN9CN30gw for instructions for unified targets!

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within a week.

[github-actions]

Pull request closed automatically as inactive.

[ctzsnooze]

I've rebased to master so this should work with Betaflight 4.5, to test it in comparison to the method currently used in 4.5.

[nerdCopter]

I've rebased to master so this should work with Betaflight 4.5, to test it in comparison to the method currently used in 4.5.

the commit history did not update because the PR was closed.

sometimes it is possible to re-opon a blocked PR after a force-push, but unsure in this case, or if it's worth the trouble.
https://gist.github.com/robertpainsi/2c42c15f1ce6dab03a0675348edd4e2c

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within a week.

[github-actions]

Pull request closed automatically as inactive.

[ctzsnooze]

Close in favour of #13488