Funny bug in EKF 3 ?!

Today i observed a quite strange behavior: i can’t fly higher than RNGFND_MAX (which is 120cm in my case; VL53L0X lidar)
Even if i disable the rangefinder over radio (via rc_option) it is still active ! although ctrl-f window of mission planner says, it’s disabled - grazy

Here’s a log:
49 01.01.1980 01-00-00.bin (676 KB)

How did you set the EK3
More specifically ;Did you set the rangefinder as the primary altitude sensor on ek3 ?

That happen (to me) when you set the rangefinder as primary altitude sensor and fly on opticalflow in Loiter Mode.

One way to go above , is to switch to Stabilize and go above limit altitude, but beware this is breaking the ekf and you can get into trouble fast…

Patrick, here are my parameters.
The strange thing is:even when i disable the rangefinder, i can’t fly higher than RNGFND_MAX. To be clear: that happens in simple AltHold mode and rangefinder disabled, no optical flow, nothing
Meanwhile i’m pretty sure this is a major bug in that firmware and not my fault.

50 01.01.1980 01-00-00.bin.log.param (15.0 KB)

Meanwhile i did 2 experiments:

  1. i set RNGFND_ADDR = 0 -> no change, can’t fly higher than 1 meter
  2. i disconnected the wires from the rangefinder -> no change, can’t fly higher than 1 meter

crazy
what prevents this firmware from allowing a higher altitude ?

My question is, what is the EK3_ALT_SOURCE ?

  • 0 : use barometer (default)
  • 1 : use range finder.
  • 2 : use GPS.

It’s 0 : use barometer (default)
(i posted all parameters 3 posts above)

ok , I looked at it it seems ok
Try this: disable optical flow and try alt-Hold

ok, tried it: disabled OF, even pulled the wire from tx line of of-sensor and armed in AltHold
->no change, copter rises to approx. 1 meter and that’s it.

as said, crazy

omg… look like you have a fence enabled …

No, fence is disabled by radio switch when i fly indoors.
Otherwise it’s not possible to arm : Prearm: fence (gps required). I fly in the basement of my house, means no gps available)

Btw: i have set the fence height (for outdoor flying to FENCE_ALT_MAX = 80m, so not only 120cm !!!)

lets meet on the general channel, it might be more efficient :

i have no account for this. Hope that one of the devs looks at the log.
The bug is absolutely reproducible

ok, int he meantime , I would suggest the “microsoft tech support option” … flush parameters and reload a new image :wink:

believe it or not: that’s exactly what i did ! (without success)

Btw.: i saw that you used the VL53L0X lidar too. Did you also observe a “Bad Lidar health” message in mission planner all the time ?

The VL53L0X need to facing a distance less than 120 cm ALL THE TIME. If you work on the bench it cannot be sitting looking up as the ceiling (on my setup ) is 170 cm so generating an error at starup

I observe this error message all the time with the sensor in less than 120cm distance. The sensors measurement is very precise, despite that Mission Planner throws that error message all the time

I dont have constant error here, what is your FC & Firmware release

FC is a so called Pixhawk lite (China quality product). Firmware ist 3.6.4 or 3.7 doesn’t matter.
I tried 2 different VL53L0X - have no i2c errors - strange

Another question that i have: there is a firmware version for Pixhawk1 and another firmware version for “fmuv2”. What’s the difference ? I allways thought Pixhawk1 = fmuv2

Actually there are 2 versions of the original PixHawk, V1 was short live and most clones are V2.
https://docs.px4.io/en/flight_controller/pixhawk_series.html#fmu-versions

very confusing,

that’s my “PixHawk”. Which firmware shall i flash: Pixhawk1, Pixhawk2, fmuv2, fmuv3 ???