Smarter RoC/RoD acceleration limit

[digitalentity]

No description provided.

[Jetrell]

@digitalentity Can I query an effect that takes place and may be related to this.

This situation occurs when Altitude Hold is enable together with PosHold or Failsafe/RTH. using mode selection.
If a multirotor has reasonable forward momentum when PosHold or RTH mode is switch to (with Altitude hold enabled) the FC will attempt to stop the multirotor before it initiates the function i.e. Poshold or RTH.
The issue comes when the FC is also trying to hold altitude under the above mention condition.
The multirotor will flip itself over violently while trying to slow down and stop.. and Hold altitude at the same time.
It only happens if Altitude Hold is enabled. Which is by default with PosHold after 2.0.

I do acknowledge that it is not ideal to be moving forward at any sort of speed when these functions are engaged. But the effect is so violent. That I had to mention it.

I would do a work around with the Taranis mixers. So to time delay Altitude Hold a few seconds after PosHold was switched. But because the two come on together by default after v2.0......

As a side note. Braking mode will help this effect a little...But it has to be operated in CRUISE mode. Which then bring about its own problems. Lets say I prefer ATTITUDE mode.

Will your work here possibly over come the violent flip over issue?

Thanks for listening Konstantin

[digitalentity]

@Jetrell do you have logs? Also, how this unmerged PR is related to the version you are testing?

[Jetrell]

@Jetrell do you have logs? Also, how this unmerged PR is related to the version you are testing?

I was thinking that this PR may alter the constraints of Altitude hold, enough to prevent a flip out when Poshold is enabled..... I am just surmising though. It will all depend on what you include to make it smarter.

I am running version 2.1. Although Nav Attitude hold had the same effect in 2.0.1 as well.
In this log. It takes place at time index 3.07

LOG00009.zip

[digitalentity]

@Jetrell thanks for the log! I'll have a look

[digitalentity]

I'm merging this as-is. If it causes issues - we'll address them towards 2.3

[Jetrell]

@digitalentity It has caused an issue Konstantin.
When FS is triggered by mode switch. The Quad instantly throttles UP to RTH.

But when a signal loss FS occurs. The flight controller reacts to the RX failsafe throttle set point. Which is... and should be set to Zero. As per manufactures RX FS recommendations.
So when a RX FS condition occurs. The FC see's the RX FS throttle set point, and drops the throttle output to Zero, for up to 1.5seconds, before the FC finally reacts to ROD and raises the throttle. By this time the quad has hit the ground.

It didn't do this in 2.1. It has only turned up in 2.2

Thanks

If you don't have the time to fix it, before the 2.2 full release. Can I request that you remove this merge and revert it back to the way it was in 2.1?

[digitalentity]

Full log please.

[Jetrell]

@digitalentity I have been out again today. And have found the problem.
I took one of my other quads up. And the new ROC/ROD acceleration limit works brilliantly with it.
So I took my test rig up again, and have found the issue.
It appears that his test quad has had too many crashes, and must have a damaged sensor.
Here is a log sample from a FC that works.
Ignore the gyro and motor noise. This quad has not been tuned to suit 2.2, with all its extra PID functionality.

Thanks again for your reply and time.

[digitalentity]

Thanks for letting know. Yes, the accelerometer going crazy will cause uncontrolled climb in many cases (#486). We attempted to mitigate in #4681, but it's not 100% bullet-proof.