Last week I was out flying my quadcopter for a group of co workers, the flights were going pretty smoothly for about two hours or so (flying around our front office building with a joystick setup)
But for whatever reason,near the end of my last flight, the quad developed an EKF error and was switching back and forth between EKF0 and EKF1? It also wouldn’t hold altitude any longer even though it was in Loiter mode.
I am using a LightWare SF11/c for altitude hold, I assumed that it would fall back to the baro to hold alt. if it experienced an error, but didn’t seem to be the case in this situation. I also have a PX4 flow sensor on the bird but I don’t believe it was enabled at the time, I was using GPS for position hold.
I am unsure if this was a “sticky i2c bus” that I have heard about or if it was some other issue that caused it to act somewhat erratically.
Luckily there were no crashes or anything and I was able to land, but I want to know what caused it and how to prevent it again in the future.
I’m going to include a dropbox link to the log that I am pretty certain was the log from that flight as it is the only one that had an EKF error in it.
I noticed that as well but I am not really familiar with reading the graphs from the logs. i wonder what would cause the lidar to see those false values? @rmackay9 can you decipher this or tag someone who can? I need ideas on why the lidar suddenly started acting up!
Every time Lidar reports crazy distance it also reports the state flag change (from OK to OUT-OF-RANGE).
So this shall not lead to the altitude problems.
It looks like EK2_ALT_SOURCE has been set to “1” which is pretty much always a bad idea especially when flying outdoors.
As a side note, I’m not sure why so many users set this parameter. I’ve updated the wiki in a few places (like here on terrain following page), to specifically warn users that this parameter should be left at it’s default of 0.
Randy, if I set it to 0, does the drone still reference the lidar for altitude? How does it know? If I remember the 0 selection is for Baro? I’m not at my drone at the moment to look.
@Iron_Donkey, it’s described a bit on the terrain following page here. If the desire is to make the vehicle follow the terrain, it is not necessary for the estimation system (i.e. the EKF) to use the range finder as it’s altitude source… instead the control system uses the range finder to correct the target altitude.
Ok that makes more sense, I think for people like me who don’t know any better, we think the param EK2_ALT_SOURCE has to be set either to 0 or 1 depending on what we plan to use for altitude. but the way you described it does make more sense, I set mine back to 0 and set my ek2_rng_use_hgt back to -1 as well.
We have a bunch of sf11s and have noticed the error readings (130m) happens a lot. We us it for data collection and just filter it out. Sometimes entire flights have little to no real laser readings.
Yeah, when I used arducopter it was usually with a passive sf11 so that the pilot would at least have a readout with the laser altimeter, but it wasn’t usually used for flight. Couldn’t handle sub 50m flight alt and 25m forest height very well, constantly trying to adjust for the canopy, then the ground etc… Now we mainly use DJI M600 and have the instrument (with sf11) completely stand alone, this is where I’ve seen the most reading dropouts, but again, not sure the cause. However it’s been observed across 4 systems, so not just written off to a dud sensor.
We really don’t want the EKF involved in terrain following (if that’s the intention). The EKF shouldn’t be making any changes in it’s altitude estimate (or anything else) based on the range finder. So the EK2_RNG_USE_HGT should also be left at -1 to ensure the EKF is not doing anything with the range finder.
