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.

1 Like

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.

Did you manage to solve the problem?

I am afraid no, nothing that I found out as a hardware problem and now the quad is not in my possession.

Hi, sorry for missing this reply.

I think the issue is that when you’re flying in Loiter or PosHold with optical flow enabled (no GPS) the vehicle will not climb above the rangefinder’s maximum altitude (RNGFND1_MAX_CM). This is a safety feature because if it did then the EKF failsafe would immediately trigger.

I’ve created a wiki to-do issue to add this important info to the wiki.

I’m afraid that AP needs to know where it is in the world so the EKF origin needs to be set somehow. Setting the EKF origin can also be done using a Lua script so if you wanted to get really fancy you could write a script that stores the current location to some parameters every few seconds and then when the vehicle is first powered up the script could set the EKF origin using the lat, lon, alt from those parameters.

ok, but it does not look like to be related to the rangefinder’s maximum altitude as

  1. It does not happen near rangefinder max range. In the above example the maximum achieved height was 2m while RNGFND1_MAX_CM=6. Also, the 2 meters was the highest I achieved. Usually is happening near 0,5m

  2. According to wiki that I followed
    Optical Flow Sensor Testing and Setup — Copter documentation
    (I used the two position switch method),
    the ekf3 POSZ was from the barometer, not from the rangefinder or GPS.

  3. Also the above behavior does not happen if I take off in Gps mode (loiter) and mid flight change to optical flow (loiter). Then everything is working fine!

so, it continues to be a weird behavior.

I want to set up option 1, using only the optical flow sensor, MatekSys Optical Flow. However, when I change the AHRS_EKF_TYPE parameter to 3 to use EKF3, a warning message pops up saying ‘ahrs, ek3 require visual odometry.’ Has anyone encountered this issue?

Hi, I am trying to use an optical flow and a GPS at the same time, nor for transitions.

Could you please explain how to set EKF3 to take both measurements? I only found instructions on transitions at GPS / Non-GPS Transitions.

Hi @RobinD,

To use both GPS and Optical flow you can leave all the EK3_SRC1_xxx parameters at their defaults (e.g. GPS for horizontal position, horizontal velocity, vertical velocity). Then set EK3_SRC2_VELXY to 5 (optical flow) and then finally leave EK3_SRC_OPTIONS = 1 (Fuse all Velocities).

Thanks so much for your reply.