EKF3,Optical flow and GPS behavior

Hello to all,

I have set up a copter with orange cube, hereflow, Here2 gps and tfmini plus lidar (firmware, copter 4.3.3)

I am struggling to understand the fusion behavior.

By setting per wiki for regular flight

  1. Verify that EK3_ENABLE = 1, enabling EKF3

  2. Set AHRS_EKF_TYPE = 3 to use EKF3

  3. Set EK3_SRC_OPTIONS = 0 to disable FuseAllVelocities

  4. Set EK3_FLOW_DELAY depending on your optical flow sensor

  5. Set EK3_SRC1_POSXY = 3 (Primary horizontal position from GPS, set this to 0 to only use the optical flow sensor)

  6. Set EK3_SRC1_VELXY = 5 (Primary horizontal velocity from OpticalFlow)

  7. Set EK3_SRC1_POSZ = 1 (Primary vertical position from barometer)

  8. Set EK3_SRC1_VELZ = 0 (No primary vertical velocity sensor)

  9. Set EK3_SRC1_YAW = 1 (Primary yaw/heading from compass)

a) In loiter mode, the behavior is that: with a reliable gps signal it uses gps and in gps denial environment it switches to optical flow automatically?

b) If (a) is correct, why is the need of GPS / Non-GPS Transitions — Copter documentation, to have a lua script or a switch for the transition?

c) Why do we set EK3_SRC_OPTIONS to 0 to disable FuseAllVelocities?

d)Why we do not let EK3_SRC1_VELZ to 3 (gps)?

e) how I bypass the prearm: need position estimate in loiter mode, with gps denial enviroment and no groundstation to set EKF origin? (for flights in a well lit indoor area)

Any help will be appreciated.


Anyone that can help?

Hi @Nautics,

Thanks for the feedback. The optical flow setup page is not very clear so I’ll try and improve it.

There are basically 3 setups to choose from:

  1. optical flow only
  2. optical flow <-> GPS transitions (one one or the other is used at any moment)
  3. optical flow + GPS at the same time

The setup that you’re describing (and which is described on the wiki) is option 3 which I don’t recommend. I suspect if you’re looking to also use GPS then option 2 is probably better.

The idea behind option 3 was that it would give a more stable horizontal position at low altitudes (compared to using only GPS) and Paul Riseborough has a video on his youtube channel of this but it was made many years ago before we supported transitions.

Hi @rmackay9,
thanks for pointing out.

I though that setup 3 maybe was doind an auto switch as in EKF2 old times according to post: EKF2: gps and optical flow in loiter combine data? - #6 by ppoirier

Also In setup 2 the transition are either switch based or lua script based?

I tried setup 2 with manual switch and I would prefer it, if I was not having a problem/bug, I haven’t found any solution, described here: Strange flow behaviour or EFK3 switching source/initializing bug

Thanks for the help!

HI @Nautics,

OK great. So let’s look into why the takeoff didn’t work. Could you post that onboard log again?

EDIT: I posted over on the other thread but let’s keep the discussion all here.

Hi, i am looking for the option 1 : optical flow only. I have hex here optical flow and lidar lite v3. They can work separately, i don’t know how to use them together. Meanwhile i have to be at non gps mode. Can you make suggestions ? If you know a source about it or a discusson can you let me know ?

Ηι @rmackay9
I have a more clean log from a calm day.

and the original from the other post is

to sum up:
a)If I power on with the switch to optical flow only and try to takeoff, I can climb up to an altitude (this varies from 40cm to 2m) and then it stops like it had an altitude fence. This happens both at loiter and alt-hold.
b)If I switch to GPS source I can fly normally
c)If I have a takeoff with gps source and then switch to optical flow only, I still can fly normally.
Any help is greatly appreciated, as with this behavior I cannot start the drone to a GPS denial environment, which is my intention.

Please try the following to set them to work together.

  1. Setup the Lidar as normal
    LIDAR-Lite Rangefinder — Copter documentation
  2. Setup and calibrate the hereflow
    Hex HereFlow Optical Flow Sensor — Copter documentation
    but do not set the
  • Set RNGFND1_TYPE = 24 (DroneCAN)
  • Set RNGFND1_MAX_CM = 300 to set range finder’s maximum range to 3m
    so as to not use the hereflow rangefinder
  1. After Hereflow calibration, if you want to fly optical flow only,set the following:

*Verify that EK3_ENABLE = 1, enabling EKF3
*Set AHRS_EKF_TYPE = 3 to use EKF3
*Set EK3_SRC_OPTIONS = 0 to disable FuseAllVelocities
*Set EK3_SRC1_POSXY = 0 (No primary horizontal position sensor)
*Set EK3_SRC1_VELXY = 5 (Primary horizontal velocity from OpticalFlow)
*Set EK3_SRC1_POSZ = 1 (Primary vertical position from barometer)
*Set EK3_SRC1_VELZ = 0 (No primary vertical velocity sensor)
*Set EK3_SRC1_YAW = 1 (Primary yaw/heading from compass)

  1. Do not forget every time to set to mission planner EKF_origin
  2. Try out!, in a well lit enviroment, at loiter it would use only optical flow (always have alt-holt and stabilize as failsafe flightmodes) Good luck

Thank you for your quick response.

a) While using optical flow at non gps mode which flight mode should i use ? I searched and saw althold is the best mode for this but i want the drone to fly autonomously.

b) And for your third explanation did lidar lite v3 and the hex here optical flow sensor work at the same time ? While getting data from optical flow sensor for x-axis, I want to get data from lidar for height from ground.

c) Can i use lidar on flowhold mode ?

a) alt hold does not use optical flow. You normally use loiter as far as hereflow is calibrated correctly and as far I understand, auto mode too
b) you use both sensor. XY axis with optical flow z axis (height) with barometer, colerated with the lidar
c) flowhold is just a degraded loiter without the use of lidar. It is selected only when you do not have lidar istalled.

1 Like

Hi @Nautics,

OK, so from looking at the smaller log it seems to be working OK.

Because there is a lidar attached the vehicle will do surface tracking while in Loiter mode. This can be disabled by setting the SURFTRAK_MODE = 0

So below we can see the DSalt (desired “sonar” alt) in blue and SAlt (actual “sonar” alt) and they are tracking reasonably well. There is a bit of overshoot but this is a known issue that we will hopefully fix in a future release.

The only slight weird thing I see is the EKF’s altitude seems to have an offset from the barometer altitude.

… but I guess this log doesn’t show the problem re the failed takeoff if the EKF origin hasn’t been set?

Hi @rmackay9
from the same log please look at the screenshots

  1. Taking off with optical flow. You can see that after reaching about 2m the climb rate descends even if throttle is above 1500ms. Two tries (one small, one larger) of rising the throttle again, goes nearly nothing to climb DCRt. After a small commanded descent and try to climb again, copter still reaches 2,XX meters and climb rate goes down again.

  2. In this part, I landed, flipped the switch to GPS and takeoff again. You can see that climb rate is by far following strictly the throttle up to 4m. (after that I command descent)

I am concern also, that these are Desired altitudes and climp rate, the actuals also follow the desired ones.

I do not want to set EKF origin, as I want to be independent from ground station and fly loiter only indoors.
Nevertheless I tried setting the EKF origin also in another flight and same behavior.