EKF2: gps and optical flow in loiter combine data?

If i am indoor efk use optical flow and this is correct (without gps fix), but in outdoor with gps fix hdop 0.7, does optical flow still work?
The result is however an unstable quad in loiter. If in outdoor I disable optical flow with only GPS and compass I have a very stable quad instead.

This is planner’s messages in indoor with active optical flow without gps fix

Please post flight logs, and read the wiki.

Which part of the wiki?

Thanks

I’d guess the wiki on flowhold https://ardupilot.org/copter/docs/flowhold-mode.html

Thanks …I read again but I don’t understand if the optical flow stop working with good GPS fix

1 Like

Hello

Yes, actually the EKF is blending both signals and will progessively reject a bad Gps and use the opticalflow as the velocity estimator (with IMU as state estimators as well). When Gps gets back to normal the EKF will mix it back.

There is are parameters EK2 and EK3 than set the gps and other state estimators confidence levels

2 Likes

Is there a parameter specifically for setting flow confidence?

1 Like

Within the EKF, https://ardupilot.org/dev/docs/ekf2-estimation-system.html
You can set
EK2_FLOW_GATE

This sets the number of standard deviations applied to the optical flow innovation consistency check. Decreasing it makes it more likely that good measurements will be rejected. Increasing it makes it more likely that bad measurements will be accepted.

2 Likes

Great, thanks for the reply!!

I actually found this, but I think it’s the same:

EK2_FLOW_I_GATE

I will do some tests … however it would be useful for EKF2 to exclude optical flow in the presence of HDOP <1. Right now my 3" props quad flies well with GPS only outdoors, quite well indooor with only optical flow, but flies badly outdoors with GPS and OPTICAL FLOW together :frowning:

Could using the ST VL53L1X also improve stability?

Hello

The VL53L1x is indoor only, so it is not suited fo your use case.

Hi,
on the wiki i can read this:

[RNGFND1_MAX_CM] = 120 for the VL53L0X, 360 for the VL53L1X. This is the distance in cm that the rangefinder can reliably read.

360 cm is enough for the outdoors, why not use it?
Thanks!

Hello,

Because this type of sensor loose the signal when exposed to sunlight.
The ToF based on LED uses a weak signal and are not really made for outdoor sunlight.
Based on the same technology , the BENAWAKE TFMini is able to go up to 6 Meter outdoor .

1 Like

Thanks :frowning:
there are still problems with both FC omnibus nano V6 and pixhawk 1 (3dr)

Generally this error is caused by having the sensor being out of range at startup, if you aim the lidar on an object within range, it will start OK.

1 Like

I put the sensor in a downward-facing test, but I had a bad health lidar error

Humm, thats an interesting module, 3 interfaces :slight_smile:
http://wiki.sunfounder.cc/index.php?title=GY-53_VL53L0X_Laser_ToF_Flight_Time_Range_Sensor_Module_Serial_PWM_Output

Can you read the signal on the serial port ? (Using a FTDI connected to a PC or arduino )

I could try with FTDI. What software can I use on the PC for testing?

I test the Benawake TFmini today, and I must admit that for that price it is doing a very good job until 6m

1 Like

this looks very compact and could go on a 3 "quad

You can use any terminal emulator like putty