Uncommanded Ascent

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:

The Parameter list:

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

The flight controller commanded this climb because its altitude estimate was incorrect. There’s something wrong with how the EKF is using your rangefinder. Look here:

This is the beginning of your flight, and looks normal at first. The rangefinder goes up to 15 meters, but then it gets stuck at 0.25 meters. You have EK2_RNG_USE_HGT 70 and RNGFND_MAX_CM 1500, so the EKF will try to use your rangefinder as the altitude source as long as it is reading <10.5 meters. Luckily, the EKF is smart enough to realize that this value is bad, so you can see the rangefinder innovation go up to be equal to (altitude - rangefinder reading).

Unfortunately, later on it seems the EKF was tricked into thinking that the rangefinder reading was healthy:

While the drone was at ~60 meters, there was ONE good rangefinder reading. This seemed to convince the EKF that the rangefinder was trustworthy, indicated by the innovation value going to 0. Soon after, the flight controller commands the drone to climb in order to fix a small altitude error, and the drone begins the climb infinitely because the rangefinder is stuck at 0.25m. Remember, you have it configured to use the rangefinder at low altitude, and the 0.25 is a valid reading, so the FC is looking for this number to increase to update the altitude estimate.

The one thing I don’t understand is why the EKF thinks the rangefinder is stuck at 0.25 meters. According to the sensor reading, it shows 0, which is normal for a sensor that is out of range:

None of this would have happened if this 0.25 reading didn’t exist, and I don’t know where it’s coming from.

By the way, the “fix” for this would simply be to set EK2_RNG_USE_HGT 0. The FC will still make use of the rangefinder when it’s in range, but it won’t depend solely on it in any situation. This is the recommended configuration for higher altitude outdoors flying.

1 Like

Thanks for that detailed explanation.
I will study it, and that will probably lead to more questions.

The LidarLite of any type is highly discouraged.

They are in my opinion dangerous, and should be thrown out.

They are known to give fixed false readings along with other errors.

There are so many better choices

The mission is sheep herding, and reliable low altitude control is essential. Can you suggest an appropriate laser altimeter?

My go-to is the SF11B from lightware in South Africa.
It is Rock solid!

1 Like

Thanks, I’ll check that out.

I can’t comment on the LidarLite, but to be clear, I don’t think this issue is hardware-related. The lidar did what it was supposed to, I’m just not sure why the EKF interpreted it like it did. It should have ignored any reading above your configured maximum.

By the way, the 0.25m reading appears to be “normal” in that I see a similar floor value in my own flight logs. The problem is that the EKF tried to use the rangefinder outside of its configured range. I think I was wrong when I said that the 0.25m reading was valid, because I think the raw reading (which was 0) is used to determine whether it is valid.

There may be a clue here:

In watching this altimeter on multiple flights, I have not seen any dropouts below 12m AGL. My need is for altitude control from 2m to 5m and the terminal phase of landing. Is the extra weight and expense of the LightWare SF11 really warranted?

Here is a flight later that day with the LidarLite V3 holding altitude:

I am certainly willing to use the SF11 if there really are problems with the LidarLite V3.

Yeah I thought it may have come from those parameters, but that didn’t bear out when I compared it to my own flight logs and params.

I can’t comment on the quality of LidarLites, but yours seems to be doing just fine within your configured range. I personally use the LightWare SF20 which is nice and light, although more expensive than the SF11.

If it really is a problem in the Arducopter code, this should be given a very high priority. The uncommanded flyaway penetrated forbidden airspace and nearly brought the craft down on our heads at 70g.

One thing that still puzzles me is the 5m/s descent
Should have given us a 2s/m rather than 5m/s descent

The crazy descent rate was a result of the copter not being able to gauge its climb rate correctly. By the way, it’s very strongly recommended to always have a non-autopilot flight mode like Stabilize available in case something like this happens.

Yeah, I’ve been thinking about this. @philip, maybe we should ask Paul if he agrees that it was caused by the EKF attempting to use the rangefinder outside of its configured range. If so, that would be a safety-related bug.

In the meantime, I think I should reiterate that setting EK2_RNG_USE_HGT = 0 will work for you. The drone will still make use of the lidar when it’s below _MAX_CM, so your altitude hold will be steady.

Thanks for the suggestions. I did have Stabilize available, but in RTL the descent rate was not visually apparent till the craft nearly crashed. I then gave full up throttle ( Cancel Landing with throttle was set), but it was too late to avoid smacking the ground. The craft went crazy on the ground till I invoked Stabilize. I was impressed that our modified landing gear absorbed 70g without any damage to the craft. After a close inspection, we took off again - this time at low altitude. The subsequent flight is in the same log file.

Can you link this post over on discuss.ardupilot.org ?
Then we can tag Paul and Randy

I’m not exactly sure how to link a post, and I don’t want to start a parallel instance of this discussion. If you can join this to the other forum, please do it.