Flow not working anymore with default parameters

[ChristophTobler]

dc2d6e8 breaks the use of optical flow with default parameters. I had to change COM_POS_FS_EPH to about 20 for dc2d6e8#diff-1d51a813dcb26f46616f71f28aacc70dR3753 to work (EKF2 reports an EPH of about 14 when using flow in simulation).

Can we avoid having one fixed EPH value?

[dagar]

The plan was to expand the failsafe to have different thresholds based on the context. However, even before that PR commander still only had one eph value. How was this working before?

Do you have a semi-recent log from before that change?

[ChristophTobler]

So the issue is that the EKF now reports an EPH when using optical flow (~14). Before it was 0.0 and therefore always passed the EPH check.
@priseborough Any ideas how we could have a dynamic check? We probably don't want to increase the threshold in general...

[priseborough]

This is fixed with the following ecl patch: PX4/PX4-ECL@25e98be

However we should fix it in the commander because position uncertainty grows over time when reliant on optical flow and we don't want an undetermined time in flight for the position accuracy check to fail. See fix here: https://github.com/YUNEEC/Firmware/commit/1a7847886079cdcebbb2f9ab9dd63b81f777839d

These are both part of a number of optical flow use improvements in https://github.com/YUNEEC/Firmware/tree/tap-v3-product-optFlowFixes-wip

[mhkabir]

@priseborough Can we have all those fixes as a pull request to PX4 master? I'm working on OF-only navigation, and having them would be super helpful.

Also related : #9414

[priseborough]

I will rebase the ecl changes and raise a PR.

[dagar]

@ChristophTobler could you describe the full use case? Then I can update the state machine and failsafe handling appropriately.