Funny bug in EKF 3 ?!

You know when I get weird stuff like this, and it does happen, I try to erase ALL of the parameter memory by installing an entirely different firmware line, like plane or antenna tracker, then reinstall. I swear there are times when a bad parameter memory location brings over a bad value from another install when that location is not written over during a firmware install.

After hours of testing finally i found the culprit: It’s this parameter: EK3_GPS_TYPE

I had set it to 3 for indoor flying without GPS. That was obviously a mistake:
After setting it to 0 again, everything works fine and i can fly as high as i want !

BUT: I consider this as a bug in that firmware, because this parameter should simply disable GPS and not restrict flight height.

There’ s no GPS in the basement of my house anyway, so i can live with that.

It prevents you from hitting the ceiling indoors. :wink:

Glad you figured it out, these are the hardest problems. You only see them out of the corner of your eye.

Hummm … Thats weird,
I fly indoor GPS denied using this config EK3_GPS_TYPE set to 3.
Just to make sure , what happens if you set it back to 3 ?

It should restrict the height if your flying in a mode that needs location from optical flow, I guess that makes sense. You should be able to do whatever you like in the other modes, if this is not the case its a bug. Can you open a github issue.

Thanks

Imho that doesn’t make sense at all:

  1. I flew in AltHold
  2. Restricting height to 1.2m isn’t needed for optical flow. OF sensor allows much higher altitude.

I’ll check if i can reproduce that after all the flashing and if so i’ll post a second log.

If your using a rangefinder as your only altitude source in altitude hold mode it makes sence not to let you fly out of range of the range finder, as the copter would then loose all altitude information. Like wise in loiter with only optical flow you should not fly out of range. It should not effect stabilise mode.

Please look at the parameters i posted several posts above:
EK3_ALT_SOURCE = 0 means imho that rangefinder is not the only altitude source, not even the primary alt-source.
Btw.: rangefinder was not active (disabled by AUX switch)

I was trying to think of a situation that the behaviour you have observed would be desirable. This is behaviours is being falsely triggered in your case. Can you open a GitHub issue, Thanks

Hello,

There is no bug and the EKF behave as intend :
See https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_NavEKF3/AP_NavEKF3_Outputs.cpp#L111

Using optical flow you a good altitude to ground in copter frame in order to scale the opticalflow mesurements correctly. Getting over the rangefinder max value will means to lost the accuracy on opticalflow and then prevent the EKF to work.
That is why you are still blocked at 1.2m even after disabling the rangefinder. The EKF is directly getting the parameter value regardless the rangefinder state. This could be improve inside the EKF as the rangefinder management is quite a mess… but that is another story.

Thanks Pierre , that make a lot of sense, but if read correctly what is reported, the problem was active in althold as well

EKF is not link to mode…
But in this case Avoidance is enable and need good positionning from EKF and then trigger the alt limiter

Where is “Avoidance enabled” ? I don’t have any avoidance sensors

ok, here’s the result of another test flight in which i couldn’t fly higher than approx. 1.2 meter. So this behavior is reproducible.

Please note:
as one can see in the log, i pushed the throttle stick (RCIN_C3) almost to it’s max for quite a long time. Normally, the copter would have hit the ceiling immediately.

And note:
Mode = AltHold and nothing else
Flow_enable = 0
RngFnd_Addr = 0 (and disabled bei AUX switch (RC11))

EK3_Alt_Source = 0
EK3_GPS_Type = 3

here’s the rest of parameters
restrict.param (15.0 KB)

and here’s the log:

88 01.01.1980 01-00-00.bin (576 KB)

Everything work’s normal again, when i set EK3_GPS_Type = 0

looking at the code, particular where @khancyr linked. I think it is just a badly worded description for EK3_GPS_Type.

The description says 3 = No GPS

The code actual assumes 3 = optical flow.

As optical flow requires a range it is enforcing the maximum height. It looks as though If you have no rangefinder setup it simply returns 0. If you have a range finder it defaults to 70% of the maximum range - 1m or 1m which ever is larger.

I think essentially your disabling your GPS in a way that confuses the code, maybe you could just turn off the serial port and leave EK3_GPS_Type as default and try again.

Disable avoidance… You have avoid_enable to 1…
If you want do disable rangefinder, set the type to 0 and reboot.
Having no opticalflow and no gps (EK3_GPS_Type 3) will lead to a crash as you don’t any speed and position sensors…

No EK3_GPS_Type 3 said to not use the speed and position from gps, it should come from another system : opticalflow, beacon, visual odometry etc!

1 Like

ok, i can confirm that AVOID_ENABLE = 0 resolves the issue (regardless of EK3_GPS_TYPE = 3)

I didn’t pay any attention to the AVOID parameters, because i thought they belong to avoidance sensors and not to a downfacing rangefinder.

I am glad that you sort this out!

I need to check you arming_check bitmask as it look strange that you could takeoff without rangefinder and with no position estimation and still have avoidance enable. That should be doable, but maybe it is because you didn’t really disable rangefinder. It will look at that.

1 Like

I set the arming checks according to a suggestion in the wiki:
Otherwise one has to put the copter up by hand for at least 1m as i remember right …
Didn’t want this …