Crash: suspect Lidar-lite V2

Crash today with my Pixhawk1 Y6,
I need help with this crash analysis. Recently I changed my Lidar Lite V2 from PWM to i2c, got it to work with minor difficulty. After I noticed the dataflash log reported data from the Lidar even when it was out of range, or over the max altitude. As expected, the data becomes intermittent when beyond the expected range of the device. I posted the question on facebook page but had zero response. I concluded that the values may not be used by the flight controller just because the log recorded these values. Now I need to know the truth.

Today the flight was as expected until I reached 20m, that’s my max alt setting for the Lidar. Then I had an uncontrolled acceleration up to 400 feet, and nearly no response to my sticks. changed flight modes, regained some control, and ended up with a severe hard landing that resulted in hundreds of dollars in damage. My principle question is “how do I avoid this in the future?”

See below the plot of baro alt (the only correct reading) vs Lidar alt (over 20m data starts defaulting to zero) vs ctun alt (the alt the gps is using) vs. gps alt
It looks like the zero reading from the Lidar is being used by the ekf regardless of the fact that its over the max altitude. Ctun Alt is at or below zero when the craft was at 400 feet!!
Eventually it came down very hard with my throttle at max.

Dataflash log file: https://1drv.ms/u/s!ArlNBOsvq-8yomOBnKfSIqLfvwfG

Any advice would be very appreciated. Not sure how to proceed.
Thank You

Did you change the primary altitude sensor for EKF?

I’m sorry to hear about your crash Hquarter. I see from your plot that the software was also suspicious of the EKF, which is why it kept swapping between EKF instance 0 and 1.

I’ve seen these kinds of drops to zero in flight on my Lidar-Lite V3 rangefinder, and I noticed that when it happened status bit 3 coming from the rangefinder went to 1, which the manual describes as “Peak not detected in correlation record, measurement is invalid”. I modified my driver code to not use rangefinder data when this happens. I don’t know if this would work for V2 because I don’t know if that status register works the same for V2. If you’re interested in the code I have it on github, https://github.com/huttonsoftware/ardupilot/tree/LidarLiteV3DualPhase_dev.

John

No, Primary Altitude Sensor is Baro.

Thanks for your reply, I’ll try your driver, but I have a serious repair to deal with first. It may be a few weeks before I have results.

Currently, I need to know IF (the lidar lite dropping to zero) is actually the cause of the incorrect altitude reading (ctun alt) or if some other issue is causing the loss of control. I have has two or three flights with the lidar acting this way and I have had a few minor (2-3m) unexplained elevation variations, but nothing like this.

Hello @Hquarter,

I’m deeply sorry for what happened.
I checked quickly your logs, and I saw in your parameters that EK2_ALT_SOURCE = 1, which means the altitude is based on the Lidar.
I recommand you to use EK2_ALT_SOURCE = 0, to be based on the barometer by default.
Then, the drone will use the range finder (which is here your Lidar) when its altitude is below EK2_RNG_USE_HGT (Range finder switch height percentage)*RNGFND_MAX_CM.
The altitude will be more stable, because if the Lidar starts to go crazy, then the estimation of the altitude will trust the barometer.
It is not fixing your issue, but at least prevent your drone to have this behavior about the altitude.

1 Like

That’s shocking as I understand the importance of the barometer acting as the primary ekf altitude source. I’ll check the parameters and verify this afternoon.
This would explain this event.

Looks like i found it on first try :slight_smile:

1 Like

Yes, you did.
I wish it was not so. But this explains everything. So hard to believe I have been flying this way, I did recognize some minor altitude problems, checked lots of settings, but did not check the most obvious setting, arrogantly thinking I could never get that wrong.

Glad to be of help. I think 99,9% you find your prob.

Thanks again for your help, but this does lead to another question.
So if I set the primary altitude sensor to be the Lidar device, and fly over the max altitude that the Lidar is configured for, the flight controller will not default back to the baro, but continue to use the “bad” Lidar data? In what condition would this be useful?

What i think is the problem in your case is that the lidar gives back a zero reading when is out of reach. So EKF thinks it is near the ground and adds motor.
A couple of years ago i made the same mistake, changed primary altitude source to lidar. One day i was flying and there was a little fog, the lidar in the fog was reading always 1-2 meters so the EKF fed in motor, don’t understanding why the aircraft wasn’t climbing (wich it was and very fast). In the end it climbed up to 1200 feet until it cleared the fog than stopped…we had a lot of fun bringing it down in one piece :slight_smile:
So in the end NEVER have lidar as primary altitude sensor :slight_smile:

2 Likes

Yes, I have followed meany posts in this forum that started and ended with the primary alt sensor set to anything but the baro. Never easy to see its all my fault.
So, in what condition would it be appropriate to use the Lidar, or GPS, or another rangefinder, as the primary altitude sensor?

From my experience i would say never use lidar as primary, i know some people use gps but i prefer baro.

1 Like

To my knowledge, using Lidar as primary source is used only in one particular scenario : Indoor navigation, where the floor is perfectly flat, and you have a complete trust in your lidar data.
But for me, even if I’m doing experience in this condition, I prefer the baro as primary source, “just in case of”.
Otherwise, never use this configuration.