Continuing from over at the CubePilot forum
Can you guys have a look over this guy’s logs?
Is anybody looking into this?
A recap:
Saturday I experienced an uncommanded Ascent to 230m. I have been pouring over the log trying to understand the cause, but see nothing. The craft is a modified Tarot Ironman 650 with a standard Cube Black and Here 2 (Serial Version). A LidarLite V3 is used at low altitude. The craft was stable before and has been since.
The flight log:
2019-08-31 17-27-54.bin
Google Drive file.
The Parameter list:
Uncommanded Ascent.param
Google Drive file.
A synopsis of events is below.
Pos Hold Mode
2019-08-31 17:27:57.601 Takeoff
2019-08-31 17:28:32.409 Level off at 53m
2019-08-31 17:29:10.221 Climb
2019-08-31 17:29:59.218 Level off at 123m
2019-08-31 17:34:17.037 Began descent
2019-08-31 17:34:19.230 Throttle at 1223
2019-08-31 17:34:48.441 Reached 89m AGL after 1m/s descent
2019-08-31 17:34:49.235 Throttle at 1495
2019-08-31 17:37:06.641 Began descent from 90m AGL, Throttle at 1395
2019-08-31 17:37:09.242 Throttle at 1154
2019-08-31 17:37:27.036 Reached 60m AGL after 1.5m/s descent
2019-08-31 17:37:29.049 Throttle at 1423
2019-08-31 17:37:53.449 Began uncommanded ascent
2019-08-31 17:38:19.653 Throttle at 1423
2019-08-31 17:39:48.456 Throttle still at 1423
2019-08-31 17:39:51.444 Throttle at 1020
2019-08-31 17:39:50.650 Reached 230m AGL after 0.9m/s ascent
2019-08-31 17:39:54.636 Issued RTL
2019-08-31 17:40:39.862 Began 5m/s descent
2019-08-31 17:41:21.445 70g Hard Landing
Although I cannot figure out the what caused it, but is seems that the EKF altitude is frozen from 724sec, right after an aggressive roll/pitch maneuver. Altitude innovations starts to increase from that point as well…
The fast descent was caused by the same issue.
1 Like
Thanks for the report and the log. This is quite horrible so hopefully we can get to the bottom of it and add some fixes.
As @Eosbandi says, it looks like an EKF issue because the EKF’s Altitude separates from the barometer and GPS altitudes. I strongly suspect this is caused by the EK2_RNG_USE_HGT parameter having been set to 70 instead of the default -1.
My personal view is this parameter should not be used if EK2_ALT_SOURCE = 0 but I suspect that for some reason it is being used. This put together with a glitching sonar is causing the EKF’s altitude to go bonkers.
I’ve pinged @priseborough to see if he has any ideas.
Worst case I’ll add a pre-arm check to ensure this parameter is set to -1 if EK2_ALT_SOURCE = 0.
1 Like
In the original topic, I posted this image:
It looks like the EKF started accepting the rangefinder readings because there was ONE good reading that appeared (note that the rangefinder innovation goes to 0).
What I don’t understand is:
- Why the EKF started accepting the rangefinder readings at all, since the one “good” reading was outside of the configured range
- Why the EKF rangefinder input NKF5.rng was stuck at 0.25 (which is a “valid” reading) instead of 0, which is what the rangefinder was outputting.
The “0” vs “0.25” difference probably comes from the RNGFND_GNDCLEAR param which is set to 25 (cm).
I suspected this as well, but it didn’t line up immediately when I looked at my own logs. My “stuck” value was 0.09, with a GNDCLEAR of 10 and MIN_CM of 1, suggesting that it should be GNDCLEAR - MIN_CM. But he gets a stuck value of 0.25 with both of those params set to 25. Also, it seemed backwards - shouldn’t the rangefinder input be (reading - groundclear)?
Anyways, it’s probably not really important unless this 0.25 value is used to determine whether the rangefinder reading is healthy. The suspect event is the EKF starting to accept the rangefinder readings at that altitude.
@Anubis, TBH, I’m not really sure. I don’t understand the EKF in great detail.
After a discussion with Tridge I’ve created a PR which turns off the use of the EK2_RNG_USE_HGT parameter unless EK2_ALT_SOURCE = 1/RangeFinder.
I don’t think it’s a full solution, I think there are other issues with the EKF’s consumption of range finder data, but I suspect it would have helped in this particular situation.
The PR’s been submitted for review to Tridge and Paul so it will get more discussion and review before merging and eventual release.
Txs again for the report.
1 Like
Thanks to all for evaluating this. I have just finished adding LidarLite V3 to a second quad. The sheep herding mission for the craft calls for tight altitude control between 3m and 6m. I have not seen any dropouts below 12m. If I take it to substantial altitude again, I will monitor climb rates carefully and be ready to switch into stabilize. I will be watching this discussion for some consensus parameter recommendations. One question I have is does Arducopter adjust the altitude target for Lidar slant range when the rangefinder is not normal to the ground?
@Philip_Smith, no problems, thanks again for the report. The key thing to improve safety is to return EK2_RNG_USE_HGT to -1 (the default).
Yes, copter does account for the vehicle’s lean when using a lidar for terrain following.
By the way we have Terrain Following wiki pages here (for more manual modes) and here (for autonomous modes) and there are specific warnings about not changing this EK2_RNG_USE_HGT parameter from the default. It’s a common misconception that the EKF is involved in terrain following but it’s really not.
We’re going to include some changes in Copter-4.0 (the next stable release) to hopefully reduce the chance of this kind of issue happening again.